Daniel's Notes

As an ex-IBMer, I'm still quite fond of POWER/ppc64 processors, and occasionally cross-compile kernels for 64-bit little-endian PowerPC (ppc64el/ppc64le) from my amd64 system. It's not immediately obvious what the simplest way to do this is. On Ubuntu (and I'm told, Debian) it is really very simple. Installation sudo apt install gcc-powerpc64le-linux-gnu Congrats, you now have a ppc64le cross-compiling toolchain installed! If you need other languages, g++/gccgo/gfortran/gnat/gobjc-powerpc64le-linux-gnu are also available. Kernel cd your/linux/source make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- <your usual kernel build commands here> That's it. Userspace It depends a bit on the build system. Here's how to build, for example, sed , which uses autotools ( ./configure and friends). ./configure --host powerpc64le-linux-gnu make That's it.  For a dynamically linked binary, you only need the headers for any library depende

Patchwork is a handy system that takes patches sent to a mailing list and gives you a nice web interface to track their progress through review and into the respective upstream project. It's used heavily in kernel development, and I'm one of the Patchwork maintainers. We have had some annoying bugs floating around for a while now - occasionally, patches to the Buildroot mailing list just seem to go missing . Andrew, an OzLabber and Patchwork contributor, suggested that there might be race conditions at play, as the mail server might spin up multiple process to parse messages - and these processes could run simultaneously. I have spent some time chasing down the bugs and recently sent a patch series which I hope will clean the up. I think the bugs are a pretty interesting example of how database processing can go wrong in interesting ways when you have unexpected parallelism. First, some background. TOCTTOU A couple of these bugs are TOCTTOU bugs - "Time of

Have you ever wanted to inject a GSO packet into the Linux kernel from userspace but been foiled by the lack of example code? I have good news! I have been poking at the innards of the Linux kernel's network offload/acceleration code. I've blogged about a previous aspect - GSO_BY_FRAGS - before. To recap: modern network cards have the ability to take a long data buffer (bigger than the MTU of the link) and segment it in hardware, sticking a set of common headers on the front of each segment. In Linux, GSO - Generic Segmentation Offload - provides a lot of software infrastructure for this sort of offload. Now normally all of this works automatically at the kernel level, without user intervention. However, for testing, it can be helpful to be able to construct your own GSO packets. The AF_PACKET socket type allows you to insert GSO packets from userspace using infrastructure from virtio_net. However, I was unable to find any example code on the internet that showed how to

Modern network cards have the ability to take a long data buffer (bigger than the MTU of the link) and segment it in hardware, sticking a set of common headers on the front of each segment. This has a number of variants and  a number of names: Large Send Offload, TCP Segmentation Offload, and a number of tunnel offloads. (My favourite one would have to be UFO - UDP Fragmentation Offload) In Linux, GSO - Generic Segmentation Offload - provides a lot of software infrastructure for these various offloads. GSO gives you a few perks even if you don't have hardware support: it allows you to do most of the work with a large buffer, and only split it right before you hand it to hardware. Now SCTP is a bit of a special case. Per 90017accff61 ("sctp: Add GSO support") : SCTP has this pecualiarity [sic] that its packets cannot be just segmented to (P)MTU. Its chunks must be contained in IP segments, padding respected. So we can't just generate a big skb, set gso_size to

netplan is the new default network configuration system for Ubuntu 17.10 (Artful) and onwards. It replaces /etc/network/interfaces . The YAML configuration files are quite a lot nicer but there are a couple of bugs being worked out. One quirk I discovered is that some settings - e.g. MTU - don't work if you're working with renamed interfaces when you match by name. For example, in an Artful VM with some added network interfaces, this doesn't work: network:     version: 2     ethernets:         switchdevs:             match:                 name: ens[78]             mtu: 1280     bridges:         br0:             interfaces: [switchdevs]             addresses:                 - 10.10.10.2/24 This creates the bridge, but the MTUs are unchanged: $ ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens3: <BROADCAST,MUL