Skip to content
  1. Dec 14, 2019
  2. Dec 13, 2019
  3. Dec 12, 2019
    • Daniel Borkmann's avatar
      bpf, x86, arm64: Enable jit by default when not built as always-on · 81c22041
      Daniel Borkmann authored
      After Spectre 2 fix via 290af866 ("bpf: introduce BPF_JIT_ALWAYS_ON
      config") most major distros use BPF_JIT_ALWAYS_ON configuration these days
      which compiles out the BPF interpreter entirely and always enables the
      JIT. Also given recent fix in e1608f3f
      
       ("bpf: Avoid setting bpf insns
      pages read-only when prog is jited"), we additionally avoid fragmenting
      the direct map for the BPF insns pages sitting in the general data heap
      since they are not used during execution. Latter is only needed when run
      through the interpreter.
      
      Since both x86 and arm64 JITs have seen a lot of exposure over the years,
      are generally most up to date and maintained, there is more downside in
      !BPF_JIT_ALWAYS_ON configurations to have the interpreter enabled by default
      rather than the JIT. Add a ARCH_WANT_DEFAULT_BPF_JIT config which archs can
      use to set the bpf_jit_{enable,kallsyms} to 1. Back in the days the
      bpf_jit_kallsyms knob was set to 0 by default since major distros still
      had /proc/kallsyms addresses exposed to unprivileged user space which is
      not the case anymore. Hence both knobs are set via BPF_JIT_DEFAULT_ON which
      is set to 'y' in case of BPF_JIT_ALWAYS_ON or ARCH_WANT_DEFAULT_BPF_JIT.
      
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/f78ad24795c2966efcc2ee19025fa3459f622185.1575903816.git.daniel@iogearbox.net
      81c22041
    • Daniel Borkmann's avatar
      bpf: Emit audit messages upon successful prog load and unload · bae141f5
      Daniel Borkmann authored
      
      
      Allow for audit messages to be emitted upon BPF program load and
      unload for having a timeline of events. The load itself is in
      syscall context, so additional info about the process initiating
      the BPF prog creation can be logged and later directly correlated
      to the unload event.
      
      The only info really needed from BPF side is the globally unique
      prog ID where then audit user space tooling can query / dump all
      info needed about the specific BPF program right upon load event
      and enrich the record, thus these changes needed here can be kept
      small and non-intrusive to the core.
      
      Raw example output:
      
        # auditctl -D
        # auditctl -a always,exit -F arch=x86_64 -S bpf
        # ausearch --start recent -m 1334
        ...
        ----
        time->Wed Nov 27 16:04:13 2019
        type=PROCTITLE msg=audit(1574867053.120:84664): proctitle="./bpf"
        type=SYSCALL msg=audit(1574867053.120:84664): arch=c000003e syscall=321   \
          success=yes exit=3 a0=5 a1=7ffea484fbe0 a2=70 a3=0 items=0 ppid=7477    \
          pid=12698 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001    \
          egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=4 comm="bpf"                \
          exe="/home/jolsa/auditd/audit-testsuite/tests/bpf/bpf"                  \
          subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
        type=UNKNOWN[1334] msg=audit(1574867053.120:84664): prog-id=76 op=LOAD
        ----
        time->Wed Nov 27 16:04:13 2019
        type=UNKNOWN[1334] msg=audit(1574867053.120:84665): prog-id=76 op=UNLOAD
        ...
      
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Co-developed-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Link: https://lore.kernel.org/bpf/20191206214934.11319-1-jolsa@kernel.org
      bae141f5
  4. Dec 11, 2019
  5. Dec 10, 2019
    • Nathan Chancellor's avatar
      ppp: Adjust indentation into ppp_async_input · 08cbc75f
      Nathan Chancellor authored
      Clang warns:
      
      ../drivers/net/ppp/ppp_async.c:877:6: warning: misleading indentation;
      statement is not part of the previous 'if' [-Wmisleading-indentation]
                                      ap->rpkt = skb;
                                      ^
      ../drivers/net/ppp/ppp_async.c:875:5: note: previous statement is here
                                      if (!skb)
                                      ^
      1 warning generated.
      
      This warning occurs because there is a space before the tab on this
      line. Clean up this entire block's indentation so that it is consistent
      with the Linux kernel coding style and clang no longer warns.
      
      Fixes: 6722e78c ("[PPP]: handle misaligned accesses")
      Link: https://github.com/ClangBuiltLinux/linux/issues/800
      
      
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08cbc75f
    • Nathan Chancellor's avatar
      net: smc911x: Adjust indentation in smc911x_phy_configure · 5c61e223
      Nathan Chancellor authored
      Clang warns:
      
      ../drivers/net/ethernet/smsc/smc911x.c:939:3: warning: misleading
      indentation; statement is not part of the previous 'if'
      [-Wmisleading-indentation]
               if (!lp->ctl_rfduplx)
               ^
      ../drivers/net/ethernet/smsc/smc911x.c:936:2: note: previous statement
      is here
              if (lp->ctl_rspeed != 100)
              ^
      1 warning generated.
      
      This warning occurs because there is a space after the tab on this line.
      Remove it so that the indentation is consistent with the Linux kernel
      coding style and clang no longer warns.
      
      Fixes: 0a0c72c9 ("[PATCH] RE: [PATCH 1/1] net driver: Add support for SMSC LAN911x line of ethernet chips")
      Link: https://github.com/ClangBuiltLinux/linux/issues/796
      
      
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c61e223
    • Nathan Chancellor's avatar
      net: tulip: Adjust indentation in {dmfe, uli526x}_init_module · fe06bf3d
      Nathan Chancellor authored
      Clang warns:
      
      ../drivers/net/ethernet/dec/tulip/uli526x.c:1812:3: warning: misleading
      indentation; statement is not part of the previous 'if'
      [-Wmisleading-indentation]
              switch (mode) {
              ^
      ../drivers/net/ethernet/dec/tulip/uli526x.c:1809:2: note: previous
      statement is here
              if (cr6set)
              ^
      1 warning generated.
      
      ../drivers/net/ethernet/dec/tulip/dmfe.c:2217:3: warning: misleading
      indentation; statement is not part of the previous 'if'
      [-Wmisleading-indentation]
              switch(mode) {
              ^
      ../drivers/net/ethernet/dec/tulip/dmfe.c:2214:2: note: previous
      statement is here
              if (cr6set)
              ^
      1 warning generated.
      
      This warning occurs because there is a space before the tab on these
      lines. Remove them so that the indentation is consistent with the Linux
      kernel coding style and clang no longer warns.
      
      While we are here, adjust the default block in dmfe_init_module to have
      a proper break between the label and assignment and add a space between
      the switch and opening parentheses to avoid a checkpatch warning.
      
      Fixes: e1c3e501 ("[PATCH] initialisation cleanup for ULI526x-net-driver")
      Link: https://github.com/ClangBuiltLinux/linux/issues/795
      
      
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe06bf3d
    • David S. Miller's avatar
      Merge branch 'dp83867-fix-fifo-depth' · 80bfc3b4
      David S. Miller authored
      
      
      Dan Murphy says:
      
      ====================
      Fix Tx/Rx FIFO depth for DP83867
      
      The DP83867 supports both the RGMII and SGMII modes.  The Tx and Rx FIFO depths
      are configurable in these modes but may not applicable for both modes.
      
      When the device is configured for RGMII mode the Tx FIFO depth is applicable
      and for SGMII mode both Tx and Rx FIFO depth settings are applicable.  When
      the driver was originally written only the RGMII device was available and there
      were no standard fifo-depth DT properties.
      
      The patchset converts the special ti,fifo-depth property to the standard
      tx-fifo-depth property while still allowing the ti,fifo-depth property to be
      set as to maintain backward compatibility.
      
      In addition to this change the rx-fifo-depth property support was added and only
      written when the device is configured for SGMII mode.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80bfc3b4