- 14 Oct, 2019 2 commits
-
-
Vladimir Oltean authored
We need priv->ptp_caps to hold a structure and not just a pointer, because we use container_of in the various PTP callbacks. Therefore, the sja1105_ptp_caps structure declared in the global memory of the driver serves no further purpose after copying it into priv->ptp_caps. So just populate priv->ptp_caps with the needed operations and remove sja1105_ptp_caps. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-10-14 The following pull-request contains BPF updates for your *net-next* tree. 12 days of development and 85 files changed, 1889 insertions(+), 1020 deletions(-) The main changes are: 1) auto-generation of bpf_helper_defs.h, from Andrii. 2) split of bpf_helpers.h into bpf_{helpers, helper_defs, endian, tracing}.h and move into libbpf, from Andrii. 3) Track contents of read-only maps as scalars in the verifier, from Andrii. 4) small x86 JIT optimization, from Daniel. 5) cross compilation support, from Ivan. 6) bpf flow_dissector enhancements, from Jakub and Stanislav. ==================== Signed-off-by:
-
- 13 Oct, 2019 3 commits
-
-
David S. Miller authored
Merge tag 'mac80211-next-for-net-next-2019-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== A few more small things, nothing really stands out: * minstrel improvements from Felix * a TX aggregation simplification * some additional capabilities for hwsim * minor cleanups & docs updates ==================== Signed-off-by:
-
Michal Kubecek authored
Commit c10e6cf8 ("net: genetlink: push attrbuf allocation and parsing to a separate function") moved attribute buffer allocation and attribute parsing from genl_family_rcv_msg_doit() into a separate function genl_family_rcv_msg_attrs_parse() which, unlike the previous code, calls __nlmsg_parse() even if family->maxattr is 0 (i.e. the family does its own parsing). The parser error is ignored and does not propagate out of genl_family_rcv_msg_attrs_parse() but an error message ("Unknown attribute type") is set in extack and if further processing generates no error or warning, it stays there and is interpreted as a warning by userspace. Dumpit requests are not affected as genl_family_rcv_msg_dumpit() bypasses the call of genl_family_rcv_msg_attrs_parse() if family->maxattr is zero. Move this logic inside genl_family_rcv_msg_attrs_parse() so that we don't have to handle it in each caller. v3: put the check inside genl_family_rcv_msg_attrs_parse() v2: adjust also argument of genl_family_rcv_msg_attrs_free() Fixes: c10e6cf8 ("net: genetlink: push attrbuf allocation and parsing to a separate function") Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Acked-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Soheil Hassas Yeganeh authored
tcp_zerocopy_receive() rounds down the zc->length a multiple of PAGE_SIZE. This results in two issues: - tcp_zerocopy_receive sets recv_skip_hint to the length of the receive queue if the zc->length input is smaller than the PAGE_SIZE, even though the data in receive queue could be zerocopied. - tcp_zerocopy_receive would set recv_skip_hint of 0, in cases where we have a little bit of data after the perfectly-sized packets. To fix these issues, do not store the rounded down value in zc->length. Round down the length passed to zap_page_range(), and return min(inq, zc->length) when the zap_range is 0. Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 12 Oct, 2019 31 commits
-
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== Patch #1 enforces libbpf build to have bpf_helper_defs.h ready before test BPF programs are built. Patch #2 drops obsolete BTF/pahole detection logic from Makefile. v1->v2: - drop CPU and PROBE (Martin). ==================== Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
Given lots of selftests won't work without recent enough Clang/LLVM that fully supports BTF, there is no point in maintaining outdated BTF support detection and fall-back to pahole logic. Just assume we have everything we need. Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
Andrii Nakryiko authored
Given BPF programs rely on libbpf's bpf_helper_defs.h, which is auto-generated during libbpf build, libbpf build has to happen before we attempt progs/*.c build. Enforce it as order-only dependency. Fixes: 24f25763 ("libbpf: auto-generate list of BPF helper definitions") Signed-off-by:
-
Alexei Starovoitov authored
Ivan Khoronzhuk says: ==================== This series contains mainly fixes/improvements for cross-compilation but not only, tested for arm, arm64, and intended for any arch. Also verified on native build (not cross compilation) for x86_64 and arm, arm64. Initial RFC link: https://lkml.org/lkml/2019/8/29/1665 Prev. version: https://lkml.org/lkml/2019/10/9/1045 Besides the patches given here, the RFC also contains couple patches related to llvm clang arm: include: asm: swab: mask rev16 instruction for clang arm: include: asm: unified: mask .syntax unified for clang They are necessarily to verify arm 32 build. Also, couple more fixes were added but are not merged in bpf-next yet, they can be needed for verification/configuration steps, if not in your tree the fixes can be taken here: https://www.spinics.net/lists/netdev/msg601716.html https://www.spinics.net/lists/netdev/msg601714.html https://www.spinics.net/lists/linux-kbuild/msg23468.html Now, to build samples, SAMPLE_BPF should be enabled in config. The change touches not only cross-compilation and can have impact on other archs and build environments, so might be good idea to verify it in order to add appropriate changes, some warn options could be tuned also. All is tested on x86-64 with clang installed (has to be built containing targets for arm, arm64..., see llc --version, usually it's present already) Instructions to test native on x86_64 ================================================= Native build on x86_64 is done in usual way and shouldn't have difference except HOSTCC is now printed as CC wile building the samples. Instructions to test cross compilation on arm64 ================================================= gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) I've used sdk for TI am65x got here: http://downloads.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07-Linux-x86-Install.bin make ARCH=arm64 -C tools/ clean make ARCH=arm64 -C samples/bpf clean make ARCH=arm64 clean make ARCH=arm64 defconfig make ARCH=arm64 headers_install make ARCH=arm64 INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07/linux-devkit/sysroots/\ aarch64-linux/usr headers_install make samples/bpf/ ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am65xx-evm-06.00.00.07/\ linux-devkit/sysroots/aarch64-linux" Instructions to test cross compilation on arm ================================================= arm-linux-gnueabihf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 or arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 \ (arm-rel-8.36)) 8.3.0 http://downloads.ti.com/processor-sdk-linux/esd/AM57X/05_03_00_07/exports/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07-Linux-x86-Install.bin make ARCH=arm -C tools/ clean make ARCH=arm -C samples/bpf clean make ARCH=arm clean make ARCH=arm omap2plus_defconfig make ARCH=arm headers_install make ARCH=arm INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07/linux-devkit/sysroots/\ armv7ahf-neon-linux-gnueabi/usr headers_install make samples/bpf/ ARCH=arm CROSS_COMPILE="arm-linux-gnueabihf-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am57xx-evm-05.03\ .00.07/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi" Based on bpf-next/master v5..v4: - any changes, only missed SOBs are added v4..v3: - renamed CLANG_EXTRA_CFLAGS on BPF_EXTRA_CFLAGS - used filter for ARCH_ARM_SELECTOR - omit "-fomit-frame-pointer" and use same flags for native and "cross" - used sample/bpf prefixes - use C instead of C++ compiler for test_libbpf target v3..v2: - renamed makefile.progs to makeifle.target, as more appropriate - left only __LINUX_ARM_ARCH__ for D options for arm - for host build - left options from KBUILD_HOST for compatibility reasons - split patch adding c/cxx/ld flags to libbpf by modules - moved readme change to separate patch - added patch setting options for cross-compile - fixed issue with option error for syscall_nrs.S, avoiding overlap for ccflags-y. v2..v1: - restructured patches order - split "samples: bpf: Makefile: base progs build on Makefile.progs" to make change more readable. It added couple nice extra patches. - removed redundant patch: "samples: bpf: Makefile: remove target for native build" - added fix: "samples: bpf: makefile: fix cookie_uid_helper_example obj build" - limited -D option filter only for arm - improved comments - added couple instructions to verify cross compilation for arm and arm64 arches based on TI am57xx and am65xx sdks. - corrected include a little order ==================== Tested-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Ivan Khoronzhuk authored
Add couple preparation steps: clean and configuration. Also add newly added sysroot support info to cross-compile section. Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
-
Ivan Khoronzhuk authored
Basically it only enables that was added by previous couple fixes. Sysroot contains correct libs installed and its headers. Useful when working with NFC or virtual machine. Usage example: clean (on demand) make ARCH=arm -C samples/bpf clean make ARCH=arm -C tools clean make ARCH=arm clean configure and install headers: make ARCH=arm defconfig make ARCH=arm headers_install build samples/bpf: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- samples/bpf/ \ SYSROOT="path/to/sysroot" Signed-off-by: -
Ivan Khoronzhuk authored
In order to build lib using C/LD flags of target arch, provide them to libbpf make. Signed-off-by:
-
Ivan Khoronzhuk authored
In case of C/LDFLAGS there is no way to pass them correctly to build command, for instance when --sysroot is used or external libraries are used, like -lelf, wich can be absent in toolchain. This can be used for samples/bpf cross-compiling allowing to get elf lib from sysroot. Signed-off-by:
-
Ivan Khoronzhuk authored
No need to use C++ for test_libbpf target when libbpf is on C and it can be tested with C, after this change the CXXFLAGS in makefiles can be avoided, at least in bpf samples, when sysroot is used, passing same C/LDFLAGS as for lib. Add "return 0" in test_libbpf to avoid warn, but also remove spaces at start of the lines to keep same style and avoid warns while apply. Signed-off-by:
-
Ivan Khoronzhuk authored
No need in hacking HOSTCC to be cross-compiler any more, so drop this trick and use target CC for HDR_PROBE. Signed-off-by:
-
Ivan Khoronzhuk authored
While compiling natively, the host's cflags and ldflags are equal to ones used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should have own, used for target arch. While verification, for arm, arm64 and x86_64 the following flags were used always: -Wall -O2 -fomit-frame-pointer -Wmissing-prototypes -Wstrict-prototypes So, add them as they were verified and used before adding Makefile.target and lets omit "-fomit-frame-pointer" as were proposed while review, as no sense in such optimization for samples. Signed-off-by:
-
Ivan Khoronzhuk authored
The main reason for that - HOSTCC and CC have different aims. HOSTCC is used to build programs running on host, that can cross-comple target programs with CC. It was tested for arm and arm64 cross compilation, based on linaro toolchain, but should work for others. So, in order to split cross compilation (CC) with host build (HOSTCC), lets base samples on Makefile.target. It allows to cross-compile samples/bpf programs with CC while auxialry tools running on host built with HOSTCC. Signed-off-by:
-
Ivan Khoronzhuk authored
The Makefile.target is added only and will be used in sample/bpf/Makefile later in order to switch cross-compiling to CC from HOSTCC environment. The HOSTCC is supposed to build binaries and tools running on the host afterwards, in order to simplify build or so, like "fixdep" or else. In case of cross compiling "fixdep" is executed on host when the rest samples should run on target arch. In order to build binaries for target arch with CC and tools running on host with HOSTCC, lets add Makefile.target for simplicity, having definition and routines similar to ones, used in script/Makefile.host. This allows later add cross-compilation to samples/bpf with minimum changes. The tprog stands for target programs built with CC. Makefile.target contains only stuff needed for samples/bpf, potentially can be reused later and now needed only for unblocking tricky samples/bpf cross compilation. Signed-off-by:
-
Ivan Khoronzhuk authored
Drop inclusion for bpf_load -I$(objtree)/usr/include as it is included for all objects anyway, with above line: KBUILD_HOSTCFLAGS += -I$(objtree)/usr/include Signed-off-by:
-
Ivan Khoronzhuk authored
For arm, -D__LINUX_ARM_ARCH__=X is min version used as instruction set selector and is absolutely required while parsing some parts of headers. It's present in KBUILD_CFLAGS but not in autoconf.h, so let's retrieve it from and add to programs cflags. In another case errors like "SMP is not supported" for armv7 and bunch of other errors are issued resulting to incorrect final object. Signed-off-by:
-
Ivan Khoronzhuk authored
It can overlap with CFLAGS used for libraries built with gcc if not now then in next patches. Correct it here for simplicity. Signed-off-by:
-
Ivan Khoronzhuk authored
For cross compiling the target triple can be inherited from cross-compile prefix as it's done in CLANG_FLAGS from kernel makefile. So copy-paste this decision from kernel Makefile. Signed-off-by:
-
Ivan Khoronzhuk authored
Don't list userspace "cookie_uid_helper_example" object in list for bpf objects. 'always' target is used for listing bpf programs, but 'cookie_uid_helper_example.o' is a user space ELF file, and covered by rule `per_socket_stats_example`, so shouldn't be in 'always'. Let us remove `always += cookie_uid_helper_example.o`, which avoids breaking cross compilation due to mismatched includes. Signed-off-by:
-
Ivan Khoronzhuk authored
echo should be replaced with echo -e to handle '\n' correctly, but instead, replace it with printf as some systems can't handle echo -e. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== netdevsim: add devlink health reporters support This patchset adds support for devlink health reporter interface testing. First 2 patches are small dependencies of the last 2. ==================== Signed-off-by: -
Jiri Pirko authored
Add basic tests to verify functionality of netdevsim reporters. Signed-off-by:
-
Jiri Pirko authored
Implement "empty" and "dummy" reporters. The first one is really simple and does nothing. The other one has debugfs files to trigger breakage and it is able to do recovery. The ops also implement dummy fmsg content. Signed-off-by:
-
Jiri Pirko authored
During health reporter operations, driver might want to fill-up the extack message, so propagate extack down to the health reporter ops. Signed-off-by:
-
Jiri Pirko authored
If reporter state is healthy, don't call into a driver for recover and don't increase recovery count. Signed-off-by:
-
Peter Fink authored
When the MAC address is supplied via device tree or a random MAC is generated it has to be written to the asix chip in order to receive any data. Previously in 9fb137ae ("net: usb: ax88179_178a: allow optionally getting mac address from device tree") this line was omitted because it seemed to work perfectly fine without it. But it was simply not detected because the chip keeps the mac stored even beyond a reset and it was tested on a hardware with an integrated UPS where the asix chip was permanently powered on even throughout power cycles. Fixes: 9fb137ae ("net: usb: ax88179_178a: allow optionally getting mac address from device tree") Signed-off-by:
Peter Fink <pfink@christ-es.de> Signed-off-by:
-
Vito Caputo authored
Remove pointless use of size return variable by directly returning sizes. Signed-off-by:
Vito Caputo <vcaputo@pengaru.com> Signed-off-by:
-
Vito Caputo authored
Remove pointless return variable dance. Appears vestigial from when the function did locking as seen in unix_find_socket_byinode(), but locking is handled in unix_find_socket_byname() for __unix_find_socket_byname(). Signed-off-by:
-
David S. Miller authored
Andrew Jeffery says: ==================== net: ftgmac100: Ungate RCLK for RMII on ASPEED MACs This series slightly extends the devicetree binding and driver for the FTGMAC100 to describe an optional RMII RCLK gate in the clocks property. Currently it's necessary for the kernel to ungate RCLK on the AST2600 in NCSI configurations as u-boot does not yet support NCSI (which uses the R(educed)MII). v2: * Clear up Reduced vs Reversed MII in the cover letter * Mitigate anxiety in the commit message for 1/3 * Clarify that AST2500 is also affected in the clocks property description in 2/3 * Rework the error paths and update some comments in 3/3 v1 can be found here: https://lore.kernel.org/netdev/20191008115143.14149-1-andrew@aj.id.au/ ==================== Signed-off-by:
-
Andrew Jeffery authored
The 50MHz RCLK has to be enabled before the RMII interface will function. Signed-off-by:
Andrew Jeffery <andrew@aj.id.au> Reviewed-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Andrew Jeffery authored
Critically, the AST2600 requires ungating the RMII RCLK if e.g. NCSI is in use. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Andrew Jeffery authored
The AST2600 contains an FTGMAC100-compatible MAC, although the MDIO controller previously embedded in the MAC has been moved out to a dedicated MDIO block. Signed-off-by:
-
- 11 Oct, 2019 4 commits
-
-
Andrii Nakryiko authored
Old GCC versions are producing invalid typedef for __gnuc_va_list pointing to void. Special-case this and emit valid: typedef __builtin_va_list __gnuc_va_list; Reported-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
-
Andrii Nakryiko authored
Existing BPF_CORE_READ() macro generates slightly suboptimal code. If there are intermediate pointers to be read, initial source pointer is going to be assigned into a temporary variable and then temporary variable is going to be uniformly used as a "source" pointer for all intermediate pointer reads. Schematically (ignoring all the type casts), BPF_CORE_READ(s, a, b, c) is expanded into: ({ const void *__t = src; bpf_probe_read(&__t, sizeof(*__t), &__t->a); bpf_probe_read(&__t, sizeof(*__t), &__t->b); typeof(s->a->b->c) __r; bpf_probe_read(&__r, sizeof(*__r), &__t->c); }) This initial `__t = src` makes calls more uniform, but causes slightly less optimal register usage sometimes when compiled with Clang. This can cascase into, e.g., more register spills. This patch fixes this issue by generating more optimal sequence: ({ const void *__t; bpf_probe_read(&__t, sizeof(*__t), &src->a); /* <-- src here */ bpf_probe_read(&__t, sizeof(*__t), &__t->b); typeof(s->a->b->c) __r; bpf_probe_read(&__r, sizeof(*__r), &__t->c); }) Fixes: 7db3822a ("libbpf: Add BPF_CORE_READ/BPF_CORE_READ_INTO helpers") Signed-off-by: -
Anton Ivanov authored
Fix typo 'boolian' into 'boolean'. Signed-off-by:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by:
-
Andrii Nakryiko authored
Fix "warning: cast to pointer from integer of different size" when casting u64 addr to void *. Fixes: a23740ec ("bpf: Track contents of read-only maps as scalars") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
