summaryrefslogtreecommitdiff
path: root/tools/build/feature/test-jvmti.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-02-08 15:25:19 -0500
committerDavid S. Miller <davem@davemloft.net>2017-02-08 15:25:19 -0500
commitd9e1661dab02e62a2ce971cfc2b957ee52f7cdf3 (patch)
tree0e66a1565e9c0bfd642ac18ecb607d2b074d0253 /tools/build/feature/test-jvmti.c
parentb05d0cfa1932376dc388a0fe67564572a84374a3 (diff)
parent9665b74562ab95bcf1b0684d599bc6779c433fca (diff)
Merge branch 'mlxsw-Reflect-nexthop-status-changes'
Jiri Pirko says: ==================== mlxsw: Reflect nexthop status changes Ido says: When the kernel forwards IPv4 packets via multipath routes it doesn't consider nexthops that are dead or linkdown. For example, if the nexthop netdev is administratively down or doesn't have a carrier. Devices capable of offloading such multipath routes need to be made aware of changes in the reflected nexthops' status. Otherwise, the device might forward packets via non-functional nexthops, resulting in packet loss. This patchset aims to fix that. The first 11 patches deal with the necessary restructuring in the mlxsw driver, so that it's able to correctly add and remove nexthops from the device's adjacency table. The 12th patch adds the NH_{ADD,DEL} events to the FIB notification chain. These notifications are sent whenever the kernel decides to add or remove a nexthop from the forwarding plane. Finally, the last three patches add support for these events in the mlxsw driver, which is currently the only driver capable of offloading multipath routes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/build/feature/test-jvmti.c')
0 files changed, 0 insertions, 0 deletions
de.c uses it to hash 16-bit unicode symbols not bytes - Modify bytemask_from_count to handle inputs of 1..sizeof(long) rather than 0..sizeof(long)-1. This would simplify users other than full_name_hash" Special thanks to Bruce Fields for testing and finding bugs in v1. (I learned some humbling lessons about "obviously correct" code.) On the arch-specific front, the m68k assembly has been tested in a standalone test harness, I've been in contact with the Microblaze maintainers who mostly don't care, as the hardware multiplier is never omitted in real-world applications, and I haven't heard anything from the H8/300 world" * 'hash' of git://ftp.sciencehorizons.net/linux: h8300: Add <asm/hash.h> microblaze: Add <asm/hash.h> m68k: Add <asm/hash.h> <linux/hash.h>: Add support for architecture-specific functions fs/namei.c: Improve dcache hash function Eliminate bad hash multipliers from hash_32() and hash_64() Change hash_64() return value to 32 bits <linux/sunrpc/svcauth.h>: Define hash_str() in terms of hashlen_string() fs/namei.c: Add hashlen_string() function Pull out string hash to <linux/stringhash.h>
Diffstat (limited to 'tools/build')