04 Aug, 2020

1 commit


05 Jun, 2020

1 commit

  • The seg6_validate_srh() is used to validate SRH for three cases:

    case1: SRH of data-plane SRv6 packets to be processed by the Linux kernel.
    Case2: SRH of the netlink message received from user-space (iproute2)
    Case3: SRH injected into packets through setsockopt

    In case1, the SRH can be encoded in the Reduced way (i.e., first SID is
    carried in DA only and not represented as SID in the SRH) and the
    seg6_validate_srh() now handles this case correctly.

    In case2 and case3, the SRH shouldn’t be encoded in the Reduced way
    otherwise we lose the first segment (i.e., the first hop).

    The current implementation of the seg6_validate_srh() allow SRH of case2
    and case3 to be encoded in the Reduced way. This leads a slab-out-of-bounds
    problem.

    This patch verifies SRH of case1, case2 and case3. Allowing case1 to be
    reduced while preventing SRH of case2 and case3 from being reduced .

    Reported-by: syzbot+e8c028b62439eac42073@syzkaller.appspotmail.com
    Reported-by: YueHaibing
    Fixes: 0cb7498f234e ("seg6: fix SRH processing to comply with RFC8754")
    Signed-off-by: Ahmed Abdelsalam
    Signed-off-by: David S. Miller

    Ahmed Abdelsalam
     

30 Mar, 2020

1 commit

  • The build_state callback of lwtunnel doesn't contain the net namespace
    structure yet. This patch will add it so we can check on specific
    address configuration at creation time of rpl source routes.

    Signed-off-by: Alexander Aring
    Signed-off-by: David S. Miller

    Alexander Aring
     

13 Mar, 2020

1 commit


12 Mar, 2020

1 commit

  • The Internet Assigned Numbers Authority (IANA) has recently assigned
    a protocol number value of 143 for Ethernet [1].

    Before this assignment, encapsulation mechanisms such as Segment Routing
    used the IPv6-NoNxt protocol number (59) to indicate that the encapsulated
    payload is an Ethernet frame.

    In this patch, we add the definition of the Ethernet protocol number to the
    kernel headers and update the SRv6 L2 tunnels to use it.

    [1] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

    Signed-off-by: Paolo Lungaroni
    Reviewed-by: Andrea Mayer
    Acked-by: Ahmed Abdelsalam
    Signed-off-by: David S. Miller

    Paolo Lungaroni
     

29 Feb, 2020

1 commit

  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: David S. Miller

    Gustavo A. R. Silva
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

28 Apr, 2019

1 commit

  • We currently have two levels of strict validation:

    1) liberal (default)
    - undefined (type >= max) & NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted
    - garbage at end of message accepted
    2) strict (opt-in)
    - NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted

    Split out parsing strictness into four different options:
    * TRAILING - check that there's no trailing data after parsing
    attributes (in message or nested)
    * MAXTYPE - reject attrs > max known type
    * UNSPEC - reject attributes with NLA_UNSPEC policy entries
    * STRICT_ATTRS - strictly validate attribute size

    The default for future things should be *everything*.
    The current *_strict() is a combination of TRAILING and MAXTYPE,
    and is renamed to _deprecated_strict().
    The current regular parsing has none of this, and is renamed to
    *_parse_deprecated().

    Additionally it allows us to selectively set one of the new flags
    even on old policies. Notably, the UNSPEC flag could be useful in
    this case, since it can be arranged (by filling in the policy) to
    not be an incompatible userspace ABI change, but would then going
    forward prevent forgetting attribute entries. Similar can apply
    to the POLICY flag.

    We end up with the following renames:
    * nla_parse -> nla_parse_deprecated
    * nla_parse_strict -> nla_parse_deprecated_strict
    * nlmsg_parse -> nlmsg_parse_deprecated
    * nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
    * nla_parse_nested -> nla_parse_nested_deprecated
    * nla_validate_nested -> nla_validate_nested_deprecated

    Using spatch, of course:
    @@
    expression TB, MAX, HEAD, LEN, POL, EXT;
    @@
    -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
    +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression TB, MAX, NLA, POL, EXT;
    @@
    -nla_parse_nested(TB, MAX, NLA, POL, EXT)
    +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)

    @@
    expression START, MAX, POL, EXT;
    @@
    -nla_validate_nested(START, MAX, POL, EXT)
    +nla_validate_nested_deprecated(START, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, MAX, POL, EXT;
    @@
    -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
    +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)

    For this patch, don't actually add the strict, non-renamed versions
    yet so that it breaks compile if I get it wrong.

    Also, while at it, make nla_validate and nla_parse go down to a
    common __nla_validate_parse() function to avoid code duplication.

    Ultimately, this allows us to have very strict validation for every
    new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
    next patch, while existing things will continue to work as is.

    In effect then, this adds fully strict validation for any new command.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

31 Jan, 2019

1 commit

  • skb->cb may contain data from previous layers (in an observed case
    IPv4 with L3 Master Device). In the observed scenario, the data in
    IPCB(skb)->frags was misinterpreted as IP6CB(skb)->frag_max_size,
    eventually caused an unexpected IPv6 fragmentation in ip6_fragment()
    through ip6_finish_output().

    This patch clears IP6CB(skb), which potentially contains garbage data,
    on the SRH ip4ip6 encapsulation.

    Fixes: 32d99d0b6702 ("ipv6: sr: add support for ip4ip6 encapsulation")
    Signed-off-by: Yohei Kanemaru
    Signed-off-by: David S. Miller

    Yohei Kanemaru
     

08 Dec, 2018

1 commit


19 Jul, 2018

1 commit

  • The rol32 call is currently rotating hash but the rol'd value is
    being discarded. I believe the current code is incorrect and hash
    should be assigned the rotated value returned from rol32.

    Detected by CoverityScan, CID#1468411 ("Useless call")

    Fixes: b5facfdba14c ("ipv6: sr: Compute flowlabel for outer IPv6 header of seg6 encap mode")
    Signed-off-by: Colin Ian King
    Acked-by: dlebrun@google.com
    Signed-off-by: David S. Miller

    Colin Ian King
     

03 Jun, 2018

1 commit


29 May, 2018

1 commit

  • seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
    out-of-bounds access when adding the SRH to the packet. This no longer
    happen when expanding the skb not only by the size of the SRH (+
    outer IPv6 header), but also by skb->mac_len.

    [ 53.793056] BUG: KASAN: use-after-free in seg6_do_srh_encap+0x284/0x620
    [ 53.794564] Write of size 14 at addr ffff88011975ecfa by task ping/674

    [ 53.796665] CPU: 0 PID: 674 Comm: ping Not tainted 4.17.0-rc3-ARCH+ #90
    [ 53.796670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS 1.11.0-20171110_100015-anatol 04/01/2014
    [ 53.796673] Call Trace:
    [ 53.796679]
    [ 53.796689] dump_stack+0x71/0xab
    [ 53.796700] print_address_description+0x6a/0x270
    [ 53.796707] kasan_report+0x258/0x380
    [ 53.796715] ? seg6_do_srh_encap+0x284/0x620
    [ 53.796722] memmove+0x34/0x50
    [ 53.796730] seg6_do_srh_encap+0x284/0x620
    [ 53.796741] ? seg6_do_srh+0x29b/0x360
    [ 53.796747] seg6_do_srh+0x29b/0x360
    [ 53.796756] seg6_input+0x2e/0x2e0
    [ 53.796765] lwtunnel_input+0x93/0xd0
    [ 53.796774] ipv6_rcv+0x690/0x920
    [ 53.796783] ? ip6_input+0x170/0x170
    [ 53.796791] ? eth_gro_receive+0x2d0/0x2d0
    [ 53.796800] ? ip6_input+0x170/0x170
    [ 53.796809] __netif_receive_skb_core+0xcc0/0x13f0
    [ 53.796820] ? netdev_info+0x110/0x110
    [ 53.796827] ? napi_complete_done+0xb6/0x170
    [ 53.796834] ? e1000_clean+0x6da/0xf70
    [ 53.796845] ? process_backlog+0x129/0x2a0
    [ 53.796853] process_backlog+0x129/0x2a0
    [ 53.796862] net_rx_action+0x211/0x5c0
    [ 53.796870] ? napi_complete_done+0x170/0x170
    [ 53.796887] ? run_rebalance_domains+0x11f/0x150
    [ 53.796891] __do_softirq+0x10e/0x39e
    [ 53.796894] do_softirq_own_stack+0x2a/0x40
    [ 53.796895]
    [ 53.796898] do_softirq.part.16+0x54/0x60
    [ 53.796900] __local_bh_enable_ip+0x5b/0x60
    [ 53.796903] ip6_finish_output2+0x416/0x9f0
    [ 53.796906] ? ip6_dst_lookup_flow+0x110/0x110
    [ 53.796909] ? ip6_sk_dst_lookup_flow+0x390/0x390
    [ 53.796911] ? __rcu_read_unlock+0x66/0x80
    [ 53.796913] ? ip6_mtu+0x44/0xf0
    [ 53.796916] ? ip6_output+0xfc/0x220
    [ 53.796918] ip6_output+0xfc/0x220
    [ 53.796921] ? ip6_finish_output+0x2b0/0x2b0
    [ 53.796923] ? memcpy+0x34/0x50
    [ 53.796926] ip6_send_skb+0x43/0xc0
    [ 53.796929] rawv6_sendmsg+0x1216/0x1530
    [ 53.796932] ? __orc_find+0x6b/0xc0
    [ 53.796934] ? rawv6_rcv_skb+0x160/0x160
    [ 53.796937] ? __rcu_read_unlock+0x66/0x80
    [ 53.796939] ? __rcu_read_unlock+0x66/0x80
    [ 53.796942] ? is_bpf_text_address+0x1e/0x30
    [ 53.796944] ? kernel_text_address+0xec/0x100
    [ 53.796946] ? __kernel_text_address+0xe/0x30
    [ 53.796948] ? unwind_get_return_address+0x2f/0x50
    [ 53.796950] ? __save_stack_trace+0x92/0x100
    [ 53.796954] ? save_stack+0x89/0xb0
    [ 53.796956] ? kasan_kmalloc+0xa0/0xd0
    [ 53.796958] ? kmem_cache_alloc+0xd2/0x1f0
    [ 53.796961] ? prepare_creds+0x23/0x160
    [ 53.796963] ? __x64_sys_capset+0x252/0x3e0
    [ 53.796966] ? do_syscall_64+0x69/0x160
    [ 53.796968] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 53.796971] ? __alloc_pages_nodemask+0x170/0x380
    [ 53.796973] ? __alloc_pages_slowpath+0x12c0/0x12c0
    [ 53.796977] ? tty_vhangup+0x20/0x20
    [ 53.796979] ? policy_nodemask+0x1a/0x90
    [ 53.796982] ? __mod_node_page_state+0x8d/0xa0
    [ 53.796986] ? __check_object_size+0xe7/0x240
    [ 53.796989] ? __sys_sendto+0x229/0x290
    [ 53.796991] ? rawv6_rcv_skb+0x160/0x160
    [ 53.796993] __sys_sendto+0x229/0x290
    [ 53.796996] ? __ia32_sys_getpeername+0x50/0x50
    [ 53.796999] ? commit_creds+0x2de/0x520
    [ 53.797002] ? security_capset+0x57/0x70
    [ 53.797004] ? __x64_sys_capset+0x29f/0x3e0
    [ 53.797007] ? __x64_sys_rt_sigsuspend+0xe0/0xe0
    [ 53.797011] ? __do_page_fault+0x664/0x770
    [ 53.797014] __x64_sys_sendto+0x74/0x90
    [ 53.797017] do_syscall_64+0x69/0x160
    [ 53.797019] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 53.797022] RIP: 0033:0x7f43b7a6714a
    [ 53.797023] RSP: 002b:00007ffd891bd368 EFLAGS: 00000246 ORIG_RAX:
    000000000000002c
    [ 53.797026] RAX: ffffffffffffffda RBX: 00000000006129c0 RCX: 00007f43b7a6714a
    [ 53.797028] RDX: 0000000000000040 RSI: 00000000006129c0 RDI: 0000000000000004
    [ 53.797029] RBP: 00007ffd891be640 R08: 0000000000610940 R09: 000000000000001c
    [ 53.797030] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
    [ 53.797032] R13: 000000000060e6a0 R14: 0000000000008004 R15: 000000000040b661

    [ 53.797171] Allocated by task 642:
    [ 53.797460] kasan_kmalloc+0xa0/0xd0
    [ 53.797463] kmem_cache_alloc+0xd2/0x1f0
    [ 53.797465] getname_flags+0x40/0x210
    [ 53.797467] user_path_at_empty+0x1d/0x40
    [ 53.797469] do_faccessat+0x12a/0x320
    [ 53.797471] do_syscall_64+0x69/0x160
    [ 53.797473] entry_SYSCALL_64_after_hwframe+0x44/0xa9

    [ 53.797607] Freed by task 642:
    [ 53.797869] __kasan_slab_free+0x130/0x180
    [ 53.797871] kmem_cache_free+0xa8/0x230
    [ 53.797872] filename_lookup+0x15b/0x230
    [ 53.797874] do_faccessat+0x12a/0x320
    [ 53.797876] do_syscall_64+0x69/0x160
    [ 53.797878] entry_SYSCALL_64_after_hwframe+0x44/0xa9

    [ 53.798014] The buggy address belongs to the object at ffff88011975e600
    which belongs to the cache names_cache of size 4096
    [ 53.799043] The buggy address is located 1786 bytes inside of
    4096-byte region [ffff88011975e600, ffff88011975f600)
    [ 53.800013] The buggy address belongs to the page:
    [ 53.800414] page:ffffea000465d600 count:1 mapcount:0
    mapping:0000000000000000 index:0x0 compound_mapcount: 0
    [ 53.801259] flags: 0x17fff0000008100(slab|head)
    [ 53.801640] raw: 017fff0000008100 0000000000000000 0000000000000000
    0000000100070007
    [ 53.803147] raw: dead000000000100 dead000000000200 ffff88011b185a40
    0000000000000000
    [ 53.803787] page dumped because: kasan: bad access detected

    [ 53.804384] Memory state around the buggy address:
    [ 53.804788] ffff88011975eb80: fb fb fb fb fb fb fb fb fb fb fb fb
    fb fb fb fb
    [ 53.805384] ffff88011975ec00: fb fb fb fb fb fb fb fb fb fb fb fb
    fb fb fb fb
    [ 53.805979] >ffff88011975ec80: fb fb fb fb fb fb fb fb fb fb fb fb
    fb fb fb fb
    [ 53.806577] ^
    [ 53.807165] ffff88011975ed00: fb fb fb fb fb fb fb fb fb fb fb fb
    fb fb fb fb
    [ 53.807762] ffff88011975ed80: fb fb fb fb fb fb fb fb fb fb fb fb
    fb fb fb fb
    [ 53.808356] ==================================================================
    [ 53.808949] Disabling lock debugging due to kernel taint

    Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: David Lebrun
    Signed-off-by: Mathieu Xhonneux
    Signed-off-by: David S. Miller

    Mathieu Xhonneux
     

01 May, 2018

1 commit

  • The seg6_make_flowlabel() is used by seg6_do_srh_encap() to compute the
    flowlabel from a given skb. It relies on skb_get_hash() which eventually
    calls __skb_flow_dissect() to extract the flow_keys struct values from
    the skb.

    In case of IPv4 traffic, calling seg6_make_flowlabel() after skb_push(),
    skb_reset_network_header(), and skb_mac_header_rebuild() will results in
    flow_keys struct of all key values set to zero.

    This patch calls seg6_make_flowlabel() before resetting the headers of skb
    to get the right key values.

    Extracted Key values are based on the type inner packet as follows:
    1) IPv6 traffic: src_IP, dst_IP, L4 proto, and flowlabel of inner packet.
    2) IPv4 traffic: src_IP, dst_IP, L4 proto, src_port, and dst_port
    3) L2 traffic: depends on what kind of traffic carried into the L2
    frame. IPv6 and IPv4 traffic works as discussed 1) and 2)

    Here a hex_dump of struct flow_keys for IPv4 and IPv6 traffic
    10.100.1.100: 47302 > 30.0.0.2: 5001
    00000000: 14 00 02 00 00 00 00 00 08 00 11 00 00 00 00 00
    00000010: 00 00 00 00 00 00 00 00 13 89 b8 c6 1e 00 00 02
    00000020: 0a 64 01 64

    fc00:a1:a > b2::2
    00000000: 28 00 03 00 00 00 00 00 86 dd 11 00 99 f9 02 00
    00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 b2 00 00
    00000020: 00 00 00 00 00 00 00 00 00 00 00 02 fc 00 00 a1
    00000030: 00 00 00 00 00 00 00 00 00 00 00 0a

    Signed-off-by: Ahmed Abdelsalam
    Signed-off-by: David S. Miller

    Ahmed Abdelsalam
     

26 Apr, 2018

1 commit

  • ECMP (equal-cost multipath) hashes are typically computed on the packets'
    5-tuple(src IP, dst IP, src port, dst port, L4 proto).

    For encapsulated packets, the L4 data is not readily available and ECMP
    hashing will often revert to (src IP, dst IP). This will lead to traffic
    polarization on a single ECMP path, causing congestion and waste of network
    capacity.

    In IPv6, the 20-bit flow label field is also used as part of the ECMP hash.
    In the lack of L4 data, the hashing will be on (src IP, dst IP, flow
    label). Having a non-zero flow label is thus important for proper traffic
    load balancing when L4 data is unavailable (i.e., when packets are
    encapsulated).

    Currently, the seg6_do_srh_encap() function extracts the original packet's
    flow label and set it as the outer IPv6 flow label. There are two issues
    with this behaviour:

    a) There is no guarantee that the inner flow label is set by the source.
    b) If the original packet is not IPv6, the flow label will be set to
    zero (e.g., IPv4 or L2 encap).

    This patch adds a function, named seg6_make_flowlabel(), that computes a
    flow label from a given skb. It supports IPv6, IPv4 and L2 payloads, and
    leverages the per namespace 'seg6_flowlabel" sysctl value.

    The currently support behaviours are as follows:
    -1 set flowlabel to zero.
    0 copy flowlabel from Inner paceket in case of Inner IPv6
    (Set flowlabel to 0 in case IPv4/L2)
    1 Compute the flowlabel using seg6_make_flowlabel()

    This patch has been tested for IPv6, IPv4, and L2 traffic.

    Signed-off-by: Ahmed Abdelsalam
    Acked-by: David Lebrun
    Signed-off-by: David S. Miller

    Ahmed Abdelsalam
     

23 Apr, 2018

1 commit

  • In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src()
    in order to set the src addr of outer IPv6 header.

    The net_device is required for set_tun_src(). However calling ip6_dst_idev()
    on dst_entry in case of IPv4 traffic results on the following bug.

    Using just dst->dev should fix this BUG.

    [ 196.242461] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    [ 196.242975] PGD 800000010f076067 P4D 800000010f076067 PUD 10f060067 PMD 0
    [ 196.243329] Oops: 0000 [#1] SMP PTI
    [ 196.243468] Modules linked in: nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd input_leds glue_helper led_class pcspkr serio_raw mac_hid video autofs4 hid_generic usbhid hid e1000 i2c_piix4 ahci pata_acpi libahci
    [ 196.244362] CPU: 2 PID: 1089 Comm: ping Not tainted 4.16.0+ #1
    [ 196.244606] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    [ 196.244968] RIP: 0010:seg6_do_srh_encap+0x1ac/0x300
    [ 196.245236] RSP: 0018:ffffb2ce00b23a60 EFLAGS: 00010202
    [ 196.245464] RAX: 0000000000000000 RBX: ffff8c7f53eea300 RCX: 0000000000000000
    [ 196.245742] RDX: 0000f10000000000 RSI: ffff8c7f52085a6c RDI: ffff8c7f41166850
    [ 196.246018] RBP: ffffb2ce00b23aa8 R08: 00000000000261e0 R09: ffff8c7f41166800
    [ 196.246294] R10: ffffdce5040ac780 R11: ffff8c7f41166828 R12: ffff8c7f41166808
    [ 196.246570] R13: ffff8c7f52085a44 R14: ffffffffb73211c0 R15: ffff8c7e69e44200
    [ 196.246846] FS: 00007fc448789700(0000) GS:ffff8c7f59d00000(0000) knlGS:0000000000000000
    [ 196.247286] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 196.247526] CR2: 0000000000000000 CR3: 000000010f05a000 CR4: 00000000000406e0
    [ 196.247804] Call Trace:
    [ 196.247972] seg6_do_srh+0x15b/0x1c0
    [ 196.248156] seg6_output+0x3c/0x220
    [ 196.248341] ? prandom_u32+0x14/0x20
    [ 196.248526] ? ip_idents_reserve+0x6c/0x80
    [ 196.248723] ? __ip_select_ident+0x90/0x100
    [ 196.248923] ? ip_append_data.part.50+0x6c/0xd0
    [ 196.249133] lwtunnel_output+0x44/0x70
    [ 196.249328] ip_send_skb+0x15/0x40
    [ 196.249515] raw_sendmsg+0x8c3/0xac0
    [ 196.249701] ? _copy_from_user+0x2e/0x60
    [ 196.249897] ? rw_copy_check_uvector+0x53/0x110
    [ 196.250106] ? _copy_from_user+0x2e/0x60
    [ 196.250299] ? copy_msghdr_from_user+0xce/0x140
    [ 196.250508] sock_sendmsg+0x36/0x40
    [ 196.250690] ___sys_sendmsg+0x292/0x2a0
    [ 196.250881] ? _cond_resched+0x15/0x30
    [ 196.251074] ? copy_termios+0x1e/0x70
    [ 196.251261] ? _copy_to_user+0x22/0x30
    [ 196.251575] ? tty_mode_ioctl+0x1c3/0x4e0
    [ 196.251782] ? _cond_resched+0x15/0x30
    [ 196.251972] ? mutex_lock+0xe/0x30
    [ 196.252152] ? vvar_fault+0xd2/0x110
    [ 196.252337] ? __do_fault+0x1f/0xc0
    [ 196.252521] ? __handle_mm_fault+0xc1f/0x12d0
    [ 196.252727] ? __sys_sendmsg+0x63/0xa0
    [ 196.252919] __sys_sendmsg+0x63/0xa0
    [ 196.253107] do_syscall_64+0x72/0x200
    [ 196.253305] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    [ 196.253530] RIP: 0033:0x7fc4480b0690
    [ 196.253715] RSP: 002b:00007ffde9f252f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [ 196.254053] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007fc4480b0690
    [ 196.254331] RDX: 0000000000000000 RSI: 000000000060a360 RDI: 0000000000000003
    [ 196.254608] RBP: 00007ffde9f253f0 R08: 00000000002d1e81 R09: 0000000000000002
    [ 196.254884] R10: 00007ffde9f250c0 R11: 0000000000000246 R12: 0000000000b22070
    [ 196.255205] R13: 20c49ba5e353f7cf R14: 431bde82d7b634db R15: 00007ffde9f278fe
    [ 196.255484] Code: a5 0f b6 45 c0 41 88 41 28 41 0f b6 41 2c 48 c1 e0 04 49 8b 54 01 38 49 8b 44 01 30 49 89 51 20 49 89 41 18 48 8b 83 b0 00 00 00 8b 30 49 8b 86 08 0b 00 00 48 8b 40 20 48 8b 50 08 48 0b 10
    [ 196.256190] RIP: seg6_do_srh_encap+0x1ac/0x300 RSP: ffffb2ce00b23a60
    [ 196.256445] CR2: 0000000000000000
    [ 196.256676] ---[ end trace 71af7d093603885c ]---

    Fixes: 8936ef7604c11 ("ipv6: sr: fix NULL pointer dereference when setting encap source address")
    Signed-off-by: Ahmed Abdelsalam
    Acked-by: David Lebrun
    Signed-off-by: David S. Miller

    Ahmed Abdelsalam
     

31 Mar, 2018

1 commit

  • Enabling TSO can lead to abysmal performances when using seg6 in
    encap mode, such as with the ixgbe driver. This patch adds a call to
    iptunnel_handle_offloads() to remove the encapsulation bit if needed.

    Before:
    root@comp4-seg6bpf:~# iperf3 -c fc00::55
    Connecting to host fc00::55, port 5201
    [ 4] local fc45::4 port 36592 connected to fc00::55 port 5201
    [ ID] Interval Transfer Bandwidth Retr Cwnd
    [ 4] 0.00-1.00 sec 196 KBytes 1.60 Mbits/sec 47 6.66 KBytes
    [ 4] 1.00-2.00 sec 304 KBytes 2.49 Mbits/sec 100 5.33 KBytes
    [ 4] 2.00-3.00 sec 284 KBytes 2.32 Mbits/sec 92 5.33 KBytes

    After:
    root@comp4-seg6bpf:~# iperf3 -c fc00::55
    Connecting to host fc00::55, port 5201
    [ 4] local fc45::4 port 43062 connected to fc00::55 port 5201
    [ ID] Interval Transfer Bandwidth Retr Cwnd
    [ 4] 0.00-1.00 sec 1.03 GBytes 8.89 Gbits/sec 0 743 KBytes
    [ 4] 1.00-2.00 sec 1.03 GBytes 8.87 Gbits/sec 0 743 KBytes
    [ 4] 2.00-3.00 sec 1.03 GBytes 8.87 Gbits/sec 0 743 KBytes

    Reported-by: Tom Herbert
    Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

23 Mar, 2018

2 commits

  • When using seg6 in encap mode, we call ipv6_dev_get_saddr() to set the
    source address of the outer IPv6 header, in case none was specified.
    Using skb->dev can lead to BUG() when it is in an inconsistent state.
    This patch uses the net_device attached to the skb's dst instead.

    [940807.667429] BUG: unable to handle kernel NULL pointer dereference at 000000000000047c
    [940807.762427] IP: ipv6_dev_get_saddr+0x8b/0x1d0
    [940807.815725] PGD 0 P4D 0
    [940807.847173] Oops: 0000 [#1] SMP PTI
    [940807.890073] Modules linked in:
    [940807.927765] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W 4.16.0-rc1-seg6bpf+ #2
    [940808.028988] Hardware name: HP ProLiant DL120 G6/ProLiant DL120 G6, BIOS O26 09/06/2010
    [940808.128128] RIP: 0010:ipv6_dev_get_saddr+0x8b/0x1d0
    [940808.187667] RSP: 0018:ffff88043fd836b0 EFLAGS: 00010206
    [940808.251366] RAX: 0000000000000005 RBX: ffff88042cb1c860 RCX: 00000000000000fe
    [940808.338025] RDX: 00000000000002c0 RSI: ffff88042cb1c860 RDI: 0000000000004500
    [940808.424683] RBP: ffff88043fd83740 R08: 0000000000000000 R09: ffffffffffffffff
    [940808.511342] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88042cb1c850
    [940808.598012] R13: ffffffff8208e380 R14: ffff88042ac8da00 R15: 0000000000000002
    [940808.684675] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
    [940808.783036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [940808.852975] CR2: 000000000000047c CR3: 00000004255fe000 CR4: 00000000000006e0
    [940808.939634] Call Trace:
    [940808.970041]
    [940808.995250] ? ip6t_do_table+0x265/0x640
    [940809.043341] seg6_do_srh_encap+0x28f/0x300
    [940809.093516] ? seg6_do_srh+0x1a0/0x210
    [940809.139528] seg6_do_srh+0x1a0/0x210
    [940809.183462] seg6_output+0x28/0x1e0
    [940809.226358] lwtunnel_output+0x3f/0x70
    [940809.272370] ip6_xmit+0x2b8/0x530
    [940809.313185] ? ac6_proc_exit+0x20/0x20
    [940809.359197] inet6_csk_xmit+0x7d/0xc0
    [940809.404173] tcp_transmit_skb+0x548/0x9a0
    [940809.453304] __tcp_retransmit_skb+0x1a8/0x7a0
    [940809.506603] ? ip6_default_advmss+0x40/0x40
    [940809.557824] ? tcp_current_mss+0x24/0x90
    [940809.605925] tcp_retransmit_skb+0xd/0x80
    [940809.654016] tcp_xmit_retransmit_queue.part.17+0xf9/0x210
    [940809.719797] tcp_ack+0xa47/0x1110
    [940809.760612] tcp_rcv_established+0x13c/0x570
    [940809.812865] tcp_v6_do_rcv+0x151/0x3d0
    [940809.858879] tcp_v6_rcv+0xa5c/0xb10
    [940809.901770] ? seg6_output+0xdd/0x1e0
    [940809.946745] ip6_input_finish+0xbb/0x460
    [940809.994837] ip6_input+0x74/0x80
    [940810.034612] ? ip6_rcv_finish+0xb0/0xb0
    [940810.081663] ipv6_rcv+0x31c/0x4c0
    ...

    Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Reported-by: Tom Herbert
    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     
  • The seg6_build_state() function is called with RCU read lock held,
    so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.

    [ 92.770271] =============================
    [ 92.770628] WARNING: suspicious RCU usage
    [ 92.770921] 4.16.0-rc4+ #12 Not tainted
    [ 92.771277] -----------------------------
    [ 92.771585] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
    [ 92.772279]
    [ 92.772279] other info that might help us debug this:
    [ 92.772279]
    [ 92.773067]
    [ 92.773067] rcu_scheduler_active = 2, debug_locks = 1
    [ 92.773514] 2 locks held by ip/2413:
    [ 92.773765] #0: (rtnl_mutex){+.+.}, at: [] rtnetlink_rcv_msg+0x441/0x4d0
    [ 92.774377] #1: (rcu_read_lock){....}, at: [] lwtunnel_build_state+0x59/0x210
    [ 92.775065]
    [ 92.775065] stack backtrace:
    [ 92.775371] CPU: 0 PID: 2413 Comm: ip Not tainted 4.16.0-rc4+ #12
    [ 92.775791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
    [ 92.776608] Call Trace:
    [ 92.776852] dump_stack+0x7d/0xbc
    [ 92.777130] __schedule+0x133/0xf00
    [ 92.777393] ? unwind_get_return_address_ptr+0x50/0x50
    [ 92.777783] ? __sched_text_start+0x8/0x8
    [ 92.778073] ? rcu_is_watching+0x19/0x30
    [ 92.778383] ? kernel_text_address+0x49/0x60
    [ 92.778800] ? __kernel_text_address+0x9/0x30
    [ 92.779241] ? unwind_get_return_address+0x29/0x40
    [ 92.779727] ? pcpu_alloc+0x102/0x8f0
    [ 92.780101] _cond_resched+0x23/0x50
    [ 92.780459] __mutex_lock+0xbd/0xad0
    [ 92.780818] ? pcpu_alloc+0x102/0x8f0
    [ 92.781194] ? seg6_build_state+0x11d/0x240
    [ 92.781611] ? save_stack+0x9b/0xb0
    [ 92.781965] ? __ww_mutex_wakeup_for_backoff+0xf0/0xf0
    [ 92.782480] ? seg6_build_state+0x11d/0x240
    [ 92.782925] ? lwtunnel_build_state+0x1bd/0x210
    [ 92.783393] ? ip6_route_info_create+0x687/0x1640
    [ 92.783846] ? ip6_route_add+0x74/0x110
    [ 92.784236] ? inet6_rtm_newroute+0x8a/0xd0

    Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

26 Aug, 2017

2 commits

  • This patch implements the L2 frame encapsulation mechanism, referred to
    as T.Encaps.L2 in the SRv6 specifications [1].

    A new type of SRv6 tunnel mode is added (SEG6_IPTUN_MODE_L2ENCAP). It only
    accepts packets with an existing MAC header (i.e., it will not work for
    locally generated packets). The resulting packet looks like IPv6 -> SRH ->
    Ethernet -> original L3 payload. The next header field of the SRH is set to
    NEXTHDR_NONE.

    [1] https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-01

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     
  • This patch enables the SRv6 encapsulation mode to carry an IPv4 payload.
    All the infrastructure was already present, I just had to add a parameter
    to seg6_do_srh_encap() to specify the inner packet protocol, and perform
    some additional checks.

    Usage example:
    ip route add 1.2.3.4 encap seg6 mode encap segs fc00::1,fc00::2 dev eth0

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

08 Aug, 2017

1 commit

  • This patch exports the seg6_do_srh_encap() and seg6_do_srh_inline()
    functions. It also removes the CONFIG_IPV6_SEG6_INLINE knob
    that enabled the compilation of seg6_do_srh_inline(). This function
    is now built-in.

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

30 May, 2017

1 commit

  • Pass extack arg down to lwtunnel_build_state and the build_state callbacks.
    Add messages for failures in lwtunnel_build_state, and add the extarg to
    nla_parse where possible in the build_state callbacks.

    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller

    David Ahern
     

18 Apr, 2017

1 commit

  • When a locally generated packet receives an SRH with two or more segments,
    the remaining headroom is too small to push an ethernet header. This patch
    ensures that the headroom is large enough after SRH push.

    The BUG generated the following trace.

    [ 192.950285] skbuff: skb_under_panic: text:ffffffff81809675 len:198 put:14 head:ffff88006f306400 data:ffff88006f3063fa tail:0xc0 end:0x2c0 dev:A-1
    [ 192.952456] ------------[ cut here ]------------
    [ 192.953218] kernel BUG at net/core/skbuff.c:105!
    [ 192.953411] invalid opcode: 0000 [#1] PREEMPT SMP
    [ 192.953411] Modules linked in:
    [ 192.953411] CPU: 5 PID: 3433 Comm: ping6 Not tainted 4.11.0-rc3+ #237
    [ 192.953411] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
    [ 192.953411] task: ffff88007c2d42c0 task.stack: ffffc90000ef4000
    [ 192.953411] RIP: 0010:skb_panic+0x61/0x70
    [ 192.953411] RSP: 0018:ffffc90000ef7900 EFLAGS: 00010286
    [ 192.953411] RAX: 0000000000000085 RBX: 00000000000086dd RCX: 0000000000000201
    [ 192.953411] RDX: 0000000080000201 RSI: ffffffff81d104c5 RDI: 00000000ffffffff
    [ 192.953411] RBP: ffffc90000ef7920 R08: 0000000000000001 R09: 0000000000000000
    [ 192.953411] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    [ 192.953411] R13: ffff88007c5a4000 R14: ffff88007b363d80 R15: 00000000000000b8
    [ 192.953411] FS: 00007f94b558b700(0000) GS:ffff88007fd40000(0000) knlGS:0000000000000000
    [ 192.953411] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 192.953411] CR2: 00007fff5ecd5080 CR3: 0000000074141000 CR4: 00000000001406e0
    [ 192.953411] Call Trace:
    [ 192.953411] skb_push+0x3b/0x40
    [ 192.953411] eth_header+0x25/0xc0
    [ 192.953411] neigh_resolve_output+0x168/0x230
    [ 192.953411] ? ip6_finish_output2+0x242/0x8f0
    [ 192.953411] ip6_finish_output2+0x242/0x8f0
    [ 192.953411] ? ip6_finish_output2+0x76/0x8f0
    [ 192.953411] ip6_finish_output+0xa8/0x1d0
    [ 192.953411] ip6_output+0x64/0x2d0
    [ 192.953411] ? ip6_output+0x73/0x2d0
    [ 192.953411] ? ip6_dst_check+0xb5/0xc0
    [ 192.953411] ? dst_cache_per_cpu_get.isra.2+0x40/0x80
    [ 192.953411] seg6_output+0xb0/0x220
    [ 192.953411] lwtunnel_output+0xcf/0x210
    [ 192.953411] ? lwtunnel_output+0x59/0x210
    [ 192.953411] ip6_local_out+0x38/0x70
    [ 192.953411] ip6_send_skb+0x2a/0xb0
    [ 192.953411] ip6_push_pending_frames+0x48/0x50
    [ 192.953411] rawv6_sendmsg+0xa39/0xf10
    [ 192.953411] ? __lock_acquire+0x489/0x890
    [ 192.953411] ? __mutex_lock+0x1fc/0x970
    [ 192.953411] ? __lock_acquire+0x489/0x890
    [ 192.953411] ? __mutex_lock+0x1fc/0x970
    [ 192.953411] ? tty_ioctl+0x283/0xec0
    [ 192.953411] inet_sendmsg+0x45/0x1d0
    [ 192.953411] ? _copy_from_user+0x54/0x80
    [ 192.953411] sock_sendmsg+0x33/0x40
    [ 192.953411] SYSC_sendto+0xef/0x170
    [ 192.953411] ? entry_SYSCALL_64_fastpath+0x5/0xc2
    [ 192.953411] ? trace_hardirqs_on_caller+0x12b/0x1b0
    [ 192.953411] ? trace_hardirqs_on_thunk+0x1a/0x1c
    [ 192.953411] SyS_sendto+0x9/0x10
    [ 192.953411] entry_SYSCALL_64_fastpath+0x1f/0xc2
    [ 192.953411] RIP: 0033:0x7f94b453db33
    [ 192.953411] RSP: 002b:00007fff5ecd0578 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    [ 192.953411] RAX: ffffffffffffffda RBX: 00007fff5ecd16e0 RCX: 00007f94b453db33
    [ 192.953411] RDX: 0000000000000040 RSI: 000055a78352e9c0 RDI: 0000000000000003
    [ 192.953411] RBP: 00007fff5ecd1690 R08: 000055a78352c940 R09: 000000000000001c
    [ 192.953411] R10: 0000000000000000 R11: 0000000000000246 R12: 000055a783321e10
    [ 192.953411] R13: 000055a7839890c0 R14: 0000000000000004 R15: 0000000000000000
    [ 192.953411] Code: 00 00 48 89 44 24 10 8b 87 c4 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 90 58 d2 81 48 89 04 24 31 c0 e8 4f 70 9a ff 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 97 d8 00 00
    [ 192.953411] RIP: skb_panic+0x61/0x70 RSP: ffffc90000ef7900
    [ 193.000186] ---[ end trace bd0b89fabdf2f92c ]---
    [ 193.000951] Kernel panic - not syncing: Fatal exception in interrupt
    [ 193.001137] Kernel Offset: disabled
    [ 193.001169] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

    Fixes: 19d5a26f5ef8de5dcb78799feaf404d717b1aac3 ("ipv6: sr: expand skb head only if necessary")
    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

14 Apr, 2017

1 commit


28 Mar, 2017

1 commit


25 Mar, 2017

2 commits

  • We already use dst_cache in seg6_output, when handling locally generated
    packets. We extend it in seg6_input, to also handle forwarded packets, and avoid
    unnecessary fib lookups.

    Performances for SRH encapsulation before the patch:
    Result: OK: 5656067(c5655678+d388) usec, 5000000 (1000byte,0frags)
    884006pps 7072Mb/sec (7072048000bps) errors: 0

    Performances after the patch:
    Result: OK: 4774543(c4774084+d459) usec, 5000000 (1000byte,0frags)
    1047220pps 8377Mb/sec (8377760000bps) errors: 0

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     
  • To insert or encapsulate a packet with an SRH, we need a large enough skb
    headroom. Currently, we are using pskb_expand_head to inconditionally increase
    the size of the headroom by the amount needed by the SRH (and IPv6 header).
    If this reallocation is performed by another CPU than the one that initially
    allocated the skb, then when the initial CPU kfree the skb, it will enter the
    __slab_free slowpath, impacting performances.

    This patch replaces pskb_expand_head with skb_cow_head, that will reallocate the
    skb head only if the headroom is not large enough.

    Performances for SRH encapsulation before the patch:
    Result: OK: 7348320(c7347271+d1048) usec, 5000000 (1000byte,0frags)
    680427pps 5443Mb/sec (5443416000bps) errors: 0

    Performances after the patch:
    Result: OK: 5656067(c5655678+d388) usec, 5000000 (1000byte,0frags)
    884006pps 7072Mb/sec (7072048000bps) errors: 0

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

08 Feb, 2017

1 commit

  • Fixes the following sparse warnings:

    net/ipv6/seg6_iptunnel.c:58:5: warning:
    symbol 'nla_put_srh' was not declared. Should it be static?
    net/ipv6/seg6_iptunnel.c:238:5: warning:
    symbol 'seg6_input' was not declared. Should it be static?
    net/ipv6/seg6_iptunnel.c:254:5: warning:
    symbol 'seg6_output' was not declared. Should it be static?

    Signed-off-by: Wei Yongjun
    Signed-off-by: David S. Miller

    Wei Yongjun
     

31 Jan, 2017

1 commit


25 Jan, 2017

1 commit


14 Jan, 2017

1 commit

  • When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
    seg6_hmac_init() is called during the initialization of the ipv6 module.
    This causes a subsequent call to smp_processor_id() with preemption
    enabled, resulting in the following trace.

    [ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
    [ 20.452556] caller is debug_smp_processor_id+0x17/0x19
    [ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
    [ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
    [ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
    [ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
    [ 20.456539] Call Trace:
    [ 20.456539] [] dump_stack+0x63/0x7f
    [ 20.456539] [] check_preemption_disabled+0xd1/0xe3
    [ 20.456539] [] debug_smp_processor_id+0x17/0x19
    [ 20.460260] [] seg6_hmac_init+0xfa/0x192 [ipv6]
    [ 20.460260] [] seg6_init+0x39/0x6f [ipv6]
    [ 20.460260] [] inet6_init+0x21a/0x321 [ipv6]
    [ 20.460260] [] ? 0xffffffffa0061000
    [ 20.460260] [] do_one_initcall+0x8b/0x115
    [ 20.460260] [] do_init_module+0x53/0x1c4
    [ 20.460260] [] load_module+0x1153/0x14ec
    [ 20.460260] [] SYSC_finit_module+0x8c/0xb9
    [ 20.460260] [] ? SYSC_finit_module+0x8c/0xb9
    [ 20.460260] [] SyS_finit_module+0x9/0xb
    [ 20.460260] [] do_syscall_64+0x62/0x75
    [ 20.460260] [] entry_SYSCALL64_slow_path+0x25/0x25

    Moreover, dst_cache_* functions also call smp_processor_id(), generating
    a similar trace.

    This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
    and disable preemption when using dst_cache_* functions.

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     

10 Nov, 2016

2 commits

  • This patch enables the verification of the HMAC signature for transiting
    SR-enabled packets, and its insertion on encapsulated/injected SRH.

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun
     
  • This patch creates a new type of interfaceless lightweight tunnel (SEG6),
    enabling the encapsulation and injection of SRH within locally emitted
    packets and forwarded packets.

    >From a configuration viewpoint, a seg6 tunnel would be configured as follows:

    ip -6 ro ad fc00::1/128 encap seg6 mode encap segs fc42::1,fc42::2,fc42::3 dev eth0

    Any packet whose destination address is fc00::1 would thus be encapsulated
    within an outer IPv6 header containing the SRH with three segments, and would
    actually be routed to the first segment of the list. If `mode inline' was
    specified instead of `mode encap', then the SRH would be directly inserted
    after the IPv6 header without outer encapsulation.

    The inline mode is only available if CONFIG_IPV6_SEG6_INLINE is enabled. This
    feature was made configurable because direct header insertion may break
    several mechanisms such as PMTUD or IPSec AH.

    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller

    David Lebrun