22 Jul, 2018

1 commit

  • [ Upstream commit 603d4cf8fe095b1ee78f423d514427be507fb513 ]

    Since the addition of GRO for ESP, gro_receive can consume the skb and
    return -EINPROGRESS. In that case, the lower layer GRO handler cannot
    touch the skb anymore.

    Commit 5f114163f2f5 ("net: Add a skb_gro_flush_final helper.") converted
    some of the gro_receive handlers that can lead to ESP's gro_receive so
    that they wouldn't access the skb when -EINPROGRESS is returned, but
    missed other spots, mainly in tunneling protocols.

    This patch finishes the conversion to using skb_gro_flush_final(), and
    adds a new helper, skb_gro_flush_final_remcsum(), used in VXLAN and
    GUE.

    Fixes: 5f114163f2f5 ("net: Add a skb_gro_flush_final helper.")
    Signed-off-by: Sabrina Dubroca
    Reviewed-by: Stefano Brivio
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Sabrina Dubroca
     

30 May, 2018

1 commit

  • [ Upstream commit cbe7128c4b92e2004984f477fd38dfa81662f02e ]

    With reorder header off, received packets are untagged in skb_vlan_untag()
    called from within __netif_receive_skb_core(), and later the tag will be
    inserted back in vlan_do_receive().

    This caused out of order vlan headers when we create a vlan device on top
    of another vlan device, because vlan_do_receive() inserts a tag as the
    outermost vlan tag. E.g. the outer tag is first removed in skb_vlan_untag()
    and inserted back in vlan_do_receive(), then the inner tag is next removed
    and inserted back as the outermost tag.

    This patch fixes the behaviour by inserting the inner tag at the right
    position.

    Signed-off-by: Toshiaki Makita
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Toshiaki Makita
     

12 Apr, 2018

1 commit

  • [ Upstream commit ec1d8ccb07deaf30fd0508af6755364ac47dc08d ]

    Just like function ethtool_get_ts_info(), we should also consider the
    phy_driver ts_info call back. For example, driver dp83640.

    Fixes: 37dd9255b2f6 ("vlan: Pass ethtool get_ts_info queries to real device.")
    Acked-by: Richard Cochran
    Signed-off-by: Hangbin Liu
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Hangbin Liu
     

17 Jan, 2018

1 commit

  • [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ]

    A vlan device with vid 0 is allow to creat by not able to be fully
    cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.

    Also, VLAN 0 is probably not a valid number and it is kinda
    "reserved" for HW accelerating devices, but it is probably too
    late to reject it from creation even if makes sense. Instead,
    just remove the check in unregister_vlan_dev().

    Reported-by: Dmitry Vyukov
    Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
    Cc: Vlad Yasevich
    Cc: Ben Hutchings
    Signed-off-by: Cong Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Cong Wang
     

11 Nov, 2017

1 commit

  • After refcnt reaches zero, vlan_vid_del() could free
    dev->vlan_info via RCU:

    RCU_INIT_POINTER(dev->vlan_info, NULL);
    call_rcu(&vlan_info->rcu, vlan_info_rcu_free);

    However, the pointer 'grp' still points to that memory
    since it is set before vlan_vid_del():

    vlan_info = rtnl_dereference(dev->vlan_info);
    if (!vlan_info)
    goto out;
    grp = &vlan_info->grp;

    Depends on when that RCU callback is scheduled, we could
    trigger a use-after-free in vlan_group_for_each_dev()
    right following this vlan_vid_del().

    Fix it by moving vlan_vid_del() before setting grp. This
    is also symmetric to the vlan_vid_add() we call in
    vlan_device_event().

    Reported-by: Fengguang Wu
    Fixes: efc73f4bbc23 ("net: Fix memory leak - vlan_info struct")
    Cc: Alexander Duyck
    Cc: Linus Torvalds
    Cc: Girish Moodalbail
    Signed-off-by: Cong Wang
    Reviewed-by: Girish Moodalbail
    Tested-by: Fengguang Wu
    Signed-off-by: David S. Miller

    Cong Wang
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

05 Oct, 2017

1 commit

  • If the vlan is down, free the packet instead of proceeding with other
    processing, or counting it as received. If vlan interfaces are used
    as slaves for bonding, with arp monitoring for connectivity, if the rx
    counter is seen to be incrementing, then the bond device will not
    observe that the interface is down.

    CC: David S. Miller
    Signed-off-by: Vishakha Narvekar
    Signed-off-by: David S. Miller

    Vishakha Narvekar
     

27 Jun, 2017

3 commits


22 Jun, 2017

1 commit


20 Jun, 2017

1 commit

  • The register_vlan_device would invoke free_netdev directly, when
    register_vlan_dev failed. It would trigger the BUG_ON in free_netdev
    if the dev was already registered. In this case, the netdev would be
    freed in netdev_run_todo later.

    So add one condition check now. Only when dev is not registered, then
    free it directly.

    The following is the part coredump when netdev_upper_dev_link failed
    in register_vlan_dev. I removed the lines which are too long.

    [ 411.237457] ------------[ cut here ]------------
    [ 411.237458] kernel BUG at net/core/dev.c:7998!
    [ 411.237484] invalid opcode: 0000 [#1] SMP
    [ 411.237705] [last unloaded: 8021q]
    [ 411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G E 4.12.0-rc5+ #6
    [ 411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
    [ 411.237764] task: ffff9cbeb6685580 task.stack: ffffa7d2807d8000
    [ 411.237782] RIP: 0010:free_netdev+0x116/0x120
    [ 411.237794] RSP: 0018:ffffa7d2807dbdb0 EFLAGS: 00010297
    [ 411.237808] RAX: 0000000000000002 RBX: ffff9cbeb6ba8fd8 RCX: 0000000000001878
    [ 411.237826] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 0000000000000000
    [ 411.237844] RBP: ffffa7d2807dbdc8 R08: 0002986100029841 R09: 0002982100029801
    [ 411.237861] R10: 0004000100029980 R11: 0004000100029980 R12: ffff9cbeb6ba9000
    [ 411.238761] R13: ffff9cbeb6ba9060 R14: ffff9cbe60f1a000 R15: ffff9cbeb6ba9000
    [ 411.239518] FS: 00007fb690d81700(0000) GS:ffff9cbebb640000(0000) knlGS:0000000000000000
    [ 411.239949] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 411.240454] CR2: 00007f7115624000 CR3: 0000000077cdf000 CR4: 00000000003406e0
    [ 411.240936] Call Trace:
    [ 411.241462] vlan_ioctl_handler+0x3f1/0x400 [8021q]
    [ 411.241910] sock_ioctl+0x18b/0x2c0
    [ 411.242394] do_vfs_ioctl+0xa1/0x5d0
    [ 411.242853] ? sock_alloc_file+0xa6/0x130
    [ 411.243465] SyS_ioctl+0x79/0x90
    [ 411.243900] entry_SYSCALL_64_fastpath+0x1e/0xa9
    [ 411.244425] RIP: 0033:0x7fb69089a357
    [ 411.244863] RSP: 002b:00007ffcd04e0fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
    [ 411.245445] RAX: ffffffffffffffda RBX: 00007ffcd04e2884 RCX: 00007fb69089a357
    [ 411.245903] RDX: 00007ffcd04e0fd0 RSI: 0000000000008983 RDI: 0000000000000003
    [ 411.246527] RBP: 00007ffcd04e0fd0 R08: 0000000000000000 R09: 1999999999999999
    [ 411.246976] R10: 000000000000053f R11: 0000000000000202 R12: 0000000000000004
    [ 411.247414] R13: 00007ffcd04e1128 R14: 00007ffcd04e2888 R15: 0000000000000001
    [ 411.249129] RIP: free_netdev+0x116/0x120 RSP: ffffa7d2807dbdb0

    Signed-off-by: Gao Feng
    Signed-off-by: David S. Miller

    Gao Feng
     

16 Jun, 2017

1 commit

  • It seems like a historic accident that these return unsigned char *,
    and in many places that means casts are required, more often than not.

    Make these functions return void * and remove all the casts across
    the tree, adding a (u8 *) cast only where the unsigned char pointer
    was used directly, all done with the following spatch:

    @@
    expression SKB, LEN;
    typedef u8;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    @@
    - *(fn(SKB, LEN))
    + *(u8 *)fn(SKB, LEN)

    @@
    expression E, SKB, LEN;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    type T;
    @@
    - E = ((T *)(fn(SKB, LEN)))
    + E = fn(SKB, LEN)

    @@
    expression SKB, LEN;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    @@
    - fn(SKB, LEN)[0]
    + *(u8 *)fn(SKB, LEN)

    Note that the last part there converts from push(...)[0] to the
    more idiomatic *(u8 *)push(...).

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

    Johannes Berg
     

15 Jun, 2017

1 commit


09 Jun, 2017

1 commit

  • Remove support for bridge bypass ndos from stacked devices. At this point
    no driver which supports stack device behavior offload supports operation
    with SELF flag. The case for upper device is already taken care of in both
    of the following cases:

    1. FDB add/del - driver should check at the notification cb if the
    stacked device contains his ports.

    2. Port attribute - calls switchdev code directly which checks
    for case of stack device.

    Signed-off-by: Arkadi Sharshevsky
    Reviewed-by: Ido Schimmel
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Arkadi Sharshevsky
     

08 Jun, 2017

1 commit

  • Network devices can allocate reasources and private memory using
    netdev_ops->ndo_init(). However, the release of these resources
    can occur in one of two different places.

    Either netdev_ops->ndo_uninit() or netdev->destructor().

    The decision of which operation frees the resources depends upon
    whether it is necessary for all netdev refs to be released before it
    is safe to perform the freeing.

    netdev_ops->ndo_uninit() presumably can occur right after the
    NETDEV_UNREGISTER notifier completes and the unicast and multicast
    address lists are flushed.

    netdev->destructor(), on the other hand, does not run until the
    netdev references all go away.

    Further complicating the situation is that netdev->destructor()
    almost universally does also a free_netdev().

    This creates a problem for the logic in register_netdevice().
    Because all callers of register_netdevice() manage the freeing
    of the netdev, and invoke free_netdev(dev) if register_netdevice()
    fails.

    If netdev_ops->ndo_init() succeeds, but something else fails inside
    of register_netdevice(), it does call ndo_ops->ndo_uninit(). But
    it is not able to invoke netdev->destructor().

    This is because netdev->destructor() will do a free_netdev() and
    then the caller of register_netdevice() will do the same.

    However, this means that the resources that would normally be released
    by netdev->destructor() will not be.

    Over the years drivers have added local hacks to deal with this, by
    invoking their destructor parts by hand when register_netdevice()
    fails.

    Many drivers do not try to deal with this, and instead we have leaks.

    Let's close this hole by formalizing the distinction between what
    private things need to be freed up by netdev->destructor() and whether
    the driver needs unregister_netdevice() to perform the free_netdev().

    netdev->priv_destructor() performs all actions to free up the private
    resources that used to be freed by netdev->destructor(), except for
    free_netdev().

    netdev->needs_free_netdev is a boolean that indicates whether
    free_netdev() should be done at the end of unregister_netdevice().

    Now, register_netdevice() can sanely release all resources after
    ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
    and netdev->priv_destructor().

    And at the end of unregister_netdevice(), we invoke
    netdev->priv_destructor() and optionally call free_netdev().

    Signed-off-by: David S. Miller

    David S. Miller
     

09 May, 2017

1 commit

  • Vlan devices, like all other software devices, enable
    NETIF_F_HW_CSUM feature. However, unlike all the othe other
    software devices, vlans will switch to using IP|IPV6_CSUM
    features, if the underlying devices uses them. In these situations,
    checksum offload features on the vlan device can't be controlled
    via ethtool.

    This patch makes vlans keep HW_CSUM feature if the underlying
    device supports checksum offloading. This makes vlan devices
    behave like other software devices, and restores control to the
    user.

    A side-effect is that some offload settings (typically UFO)
    may be enabled on the vlan device while being disabled on the HW.
    However, the GSO code will correctly process the packets. This
    actually results in slightly better raw throughput.

    Signed-off-by: Vladislav Yasevich
    Acked-by: Alexander Duyck
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

14 Apr, 2017

1 commit


22 Mar, 2017

1 commit

  • wanted_features is a set of features which have to be enabled if a
    hardware allows that.

    Currently when a vlan device is created, its wanted_features is set to
    current features of its base device.

    The problem is that the base device can get new features and they are
    not propagated to vlan-s of this device.

    If we look at bonding devices, they doesn't have this problem and this
    patch suggests to fix this issue by the same way how it works for bonding
    devices.

    We meet this problem, when we try to create a vlan device over a bonding
    device. When a system are booting, real devices require time to be
    initialized, so bonding devices created without slaves, then vlan
    devices are created and only then ethernet devices are added to the
    bonding device. As a result we have vlan devices with disabled
    scatter-gather.

    * create a bonding device
    $ ip link add bond0 type bond
    $ ethtool -k bond0 | grep scatter
    scatter-gather: off
    tx-scatter-gather: off [requested on]
    tx-scatter-gather-fraglist: off [requested on]

    * create a vlan device
    $ ip link add link bond0 name bond0.10 type vlan id 10
    $ ethtool -k bond0.10 | grep scatter
    scatter-gather: off
    tx-scatter-gather: off
    tx-scatter-gather-fraglist: off

    * Add a slave device to bond0
    $ ip link set dev eth0 master bond0

    And now we can see that the bond0 device has got the scatter-gather
    feature, but the bond0.10 hasn't got it.
    [root@laptop linux-task-diag]# ethtool -k bond0 | grep scatter
    scatter-gather: on
    tx-scatter-gather: on
    tx-scatter-gather-fraglist: on
    [root@laptop linux-task-diag]# ethtool -k bond0.10 | grep scatter
    scatter-gather: off
    tx-scatter-gather: off
    tx-scatter-gather-fraglist: off

    With this patch the vlan device will get all new features from the
    bonding device.

    Here is a call trace how features which are set in this patch reach
    dev->wanted_features.

    register_netdevice
    vlan_dev_init
    ...
    dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
    NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
    NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
    NETIF_F_ALL_FCOE;

    dev->features |= dev->hw_features;
    ...
    dev->wanted_features = dev->features & dev->hw_features;
    __netdev_update_features(dev);
    vlan_dev_fix_features
    ...

    Cc: Alexey Kuznetsov
    Cc: Patrick McHardy
    Cc: "David S. Miller"
    Signed-off-by: Andrei Vagin
    Signed-off-by: David S. Miller

    Andrey Vagin
     

07 Feb, 2017

1 commit

  • In commit 18bfb924f000 ("net: introduce default neigh_construct/destroy
    ndo calls for L2 upper devices") we added these ndos to stacked devices
    such as team and bond, so that calls will be propagated to mlxsw.

    However, previous commit removed the reliance on these ndos and no new
    users of these ndos have appeared since above mentioned commit. We can
    therefore safely remove this dead code.

    Signed-off-by: Ido Schimmel
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Ido Schimmel
     

09 Jan, 2017

1 commit

  • The network device operation for reading statistics is only called
    in one place, and it ignores the return value. Having a structure
    return value is potentially confusing because some future driver could
    incorrectly assume that the return value was used.

    Fix all drivers with ndo_get_stats64 to have a void function.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    stephen hemminger
     

25 Dec, 2016

1 commit


18 Nov, 2016

1 commit

  • Make struct pernet_operations::id unsigned.

    There are 2 reasons to do so:

    1)
    This field is really an index into an zero based array and
    thus is unsigned entity. Using negative value is out-of-bound
    access by definition.

    2)
    On x86_64 unsigned 32-bit data which are mixed with pointers
    via array indexing or offsets added or subtracted to pointers
    are preffered to signed 32-bit data.

    "int" being used as an array index needs to be sign-extended
    to 64-bit before being used.

    void f(long *p, int i)
    {
    g(p[i]);
    }

    roughly translates to

    movsx rsi, esi
    mov rdi, [rsi+...]
    call g

    MOVSX is 3 byte instruction which isn't necessary if the variable is
    unsigned because x86_64 is zero extending by default.

    Now, there is net_generic() function which, you guessed it right, uses
    "int" as an array index:

    static inline void *net_generic(const struct net *net, int id)
    {
    ...
    ptr = ng->ptr[id - 1];
    ...
    }

    And this function is used a lot, so those sign extensions add up.

    Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
    messing with code generation):

    add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)

    Unfortunately some functions actually grow bigger.
    This is a semmingly random artefact of code generation with register
    allocator being used differently. gcc decides that some variable
    needs to live in new r8+ registers and every access now requires REX
    prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
    used which is longer than [r8]

    However, overall balance is in negative direction:

    add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
    function old new delta
    nfsd4_lock 3886 3959 +73
    tipc_link_build_proto_msg 1096 1140 +44
    mac80211_hwsim_new_radio 2776 2808 +32
    tipc_mon_rcv 1032 1058 +26
    svcauth_gss_legacy_init 1413 1429 +16
    tipc_bcbase_select_primary 379 392 +13
    nfsd4_exchange_id 1247 1260 +13
    nfsd4_setclientid_confirm 782 793 +11
    ...
    put_client_renew_locked 494 480 -14
    ip_set_sockfn_get 730 716 -14
    geneve_sock_add 829 813 -16
    nfsd4_sequence_done 721 703 -18
    nlmclnt_lookup_host 708 686 -22
    nfsd4_lockt 1085 1063 -22
    nfs_get_client 1077 1050 -27
    tcf_bpf_init 1106 1076 -30
    nfsd4_encode_fattr 5997 5930 -67
    Total: Before=154856051, After=154854321, chg -0.00%

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: David S. Miller

    Alexey Dobriyan
     

31 Oct, 2016

1 commit


21 Oct, 2016

2 commits

  • geneve:
    - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
    - This one isn't quite as straight-forward as others, could use some
    closer inspection and testing

    macvlan:
    - set min/max_mtu

    tun:
    - set min/max_mtu, remove tun_net_change_mtu

    vxlan:
    - Merge __vxlan_change_mtu back into vxlan_change_mtu
    - Set max_mtu to IP_MAX_MTU and retain dynamic MTU range checks in
    change_mtu function
    - This one is also not as straight-forward and could use closer inspection
    and testing from vxlan folks

    bridge:
    - set max_mtu of IP_MAX_MTU and retain dynamic MTU range checks in
    change_mtu function

    openvswitch:
    - set min/max_mtu, remove internal_dev_change_mtu
    - note: max_mtu wasn't checked previously, it's been set to 65535, which
    is the largest possible size supported

    sch_teql:
    - set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)

    macsec:
    - min_mtu = 0, max_mtu = 65535

    macvlan:
    - min_mtu = 0, max_mtu = 65535

    ntb_netdev:
    - min_mtu = 0, max_mtu = 65535

    veth:
    - min_mtu = 68, max_mtu = 65535

    8021q:
    - min_mtu = 0, max_mtu = 65535

    CC: netdev@vger.kernel.org
    CC: Nicolas Dichtel
    CC: Hannes Frederic Sowa
    CC: Tom Herbert
    CC: Daniel Borkmann
    CC: Alexander Duyck
    CC: Paolo Abeni
    CC: Jiri Benc
    CC: WANG Cong
    CC: Roopa Prabhu
    CC: Pravin B Shelar
    CC: Sabrina Dubroca
    CC: Patrick McHardy
    CC: Stephen Hemminger
    CC: Pravin Shelar
    CC: Maxim Krasnyansky
    Signed-off-by: Jarod Wilson
    Signed-off-by: David S. Miller

    Jarod Wilson
     
  • Currently, GRO can do unlimited recursion through the gro_receive
    handlers. This was fixed for tunneling protocols by limiting tunnel GRO
    to one level with encap_mark, but both VLAN and TEB still have this
    problem. Thus, the kernel is vulnerable to a stack overflow, if we
    receive a packet composed entirely of VLAN headers.

    This patch adds a recursion counter to the GRO layer to prevent stack
    overflow. When a gro_receive function hits the recursion limit, GRO is
    aborted for this skb and it is processed normally. This recursion
    counter is put in the GRO CB, but could be turned into a percpu counter
    if we run out of space in the CB.

    Thanks to Vladimír Beneš for the initial bug report.

    Fixes: CVE-2016-7039
    Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
    Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
    Signed-off-by: Sabrina Dubroca
    Reviewed-by: Jiri Benc
    Acked-by: Hannes Frederic Sowa
    Acked-by: Tom Herbert
    Signed-off-by: David S. Miller

    Sabrina Dubroca
     

19 Oct, 2016

1 commit


18 Oct, 2016

1 commit

  • args.u.name_type is of type unsigned int and is always >= 0.

    This fixes the following GCC warning:

    net/8021q/vlan.c: In function ‘vlan_ioctl_handler’:
    net/8021q/vlan.c:574:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]

    Signed-off-by: Tobias Klauser
    Signed-off-by: David S. Miller

    Tobias Klauser
     

14 Aug, 2016

1 commit


24 Jul, 2016

1 commit


17 Jul, 2016

1 commit

  • macsec can't cope with mtu frames which need vlan tag insertion, and
    vlan device set the default mtu equal to the underlying dev's one.
    By default vlan over macsec devices use invalid mtu, dropping
    all the large packets.
    This patch adds a netif helper to check if an upper vlan device
    needs mtu reduction. The helper is used during vlan devices
    initialization to set a valid default and during mtu updating to
    forbid invalid, too bit, mtu values.
    The helper currently only check if the lower dev is a macsec device,
    if we get more users, we need to update only the helper (possibly
    reserving an additional IFF bit).

    Signed-off-by: Paolo Abeni
    Signed-off-by: David S. Miller

    Paolo Abeni
     

06 Jul, 2016

1 commit


01 Jun, 2016

1 commit

  • The MAC address of the physical interface is only copied to the VLAN
    when it is first created, resulting in an inconsistency after MAC
    address changes of only newly created VLANs having an up-to-date MAC.

    The VLANs should continue inheriting the MAC address of the physical
    interface until the VLAN MAC address is explicitly set to any value.
    This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
    to the MAC of the physical interface and thus for DAD to behave as
    expected.

    Signed-off-by: Mike Manning
    Signed-off-by: David S. Miller

    Mike Manning
     

18 Mar, 2016

1 commit


26 Feb, 2016

1 commit


22 Feb, 2016

1 commit

  • Currently vlan device inherits unicast filtering flag from underlying
    device. If underlying device doesn't support unicast filter, this will
    put vlan device into promiscuous mode when it's stacked.

    Tun on IFF_UNICAST_FLT on the vlan device in any case so that it does
    not go into promiscuous mode needlessly. If underlying device does not
    support unicast filtering, that device will enter promiscuous mode.

    Signed-off-by: Zhang Shengju
    Signed-off-by: David S. Miller

    Zhang Shengju
     

18 Feb, 2016

1 commit


16 Dec, 2015

3 commits

  • The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
    set of features for offloading all checksums. This is a mask of the
    checksum offload related features bits. It is incorrect to set both
    NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
    features of a device.

    This patch:
    - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
    NETIF_F_ALL_CSUM is being used as a mask).
    - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
    use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.

    Signed-off-by: Tom Herbert
    Signed-off-by: David S. Miller

    Tom Herbert
     
  • The SCTP checksum is really a CRC and is very different from the
    standards 1's complement checksum that serves as the checksum
    for IP protocols. This offload interface is also very different.
    Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC to highlight these
    differences. The term CSUM should be reserved in the stack to refer
    to the standard 1's complement IP checksum.

    Signed-off-by: Tom Herbert
    Signed-off-by: David S. Miller

    Tom Herbert
     
  • We need to be able to propagate static FDB entries and certain bridge
    port attributes (e.g. learning, flooding) down to the port netdev
    driver when bridge port is a VLAN interface.

    Achieve that by setting ndo_bridge* and ndo_fdb* in vlan_netdev_ops to
    the corresponding switchdev_port* functions. This is consistent with
    team and bond devices.

    Signed-off-by: Ido Schimmel
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Ido Schimmel