12 Dec, 2014

1 commit


22 Nov, 2014

2 commits


08 Oct, 2014

1 commit

  • Testing xmit_more support with netperf and connected UDP sockets,
    I found strange dst refcount false sharing.

    Current handling of IFF_XMIT_DST_RELEASE is not optimal.

    Dropping dst in validate_xmit_skb() is certainly too late in case
    packet was queued by cpu X but dequeued by cpu Y

    The logical point to take care of drop/force is in __dev_queue_xmit()
    before even taking qdisc lock.

    As Julian Anastasov pointed out, need for skb_dst() might come from some
    packet schedulers or classifiers.

    This patch adds new helper to cleanly express needs of various drivers
    or qdiscs/classifiers.

    Drivers that need skb_dst() in their ndo_start_xmit() should call
    following helper in their setup instead of the prior :

    dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
    ->
    netif_keep_dst(dev);

    Instead of using a single bit, we use two bits, one being
    eventually rebuilt in bonding/team drivers.

    The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
    rebuilt in bonding/team. Eventually, we could add something
    smarter later.

    Signed-off-by: Eric Dumazet
    Cc: Julian Anastasov
    Signed-off-by: David S. Miller

    Eric Dumazet
     

12 Aug, 2014

1 commit

  • Currently the functionality to untag traffic on input resides
    as part of the vlan module and is build only when VLAN support
    is enabled in the kernel. When VLAN is disabled, the function
    vlan_untag() turns into a stub and doesn't really untag the
    packets. This seems to create an interesting interaction
    between VMs supporting checksum offloading and some network drivers.

    There are some drivers that do not allow the user to change
    tx-vlan-offload feature of the driver. These drivers also seem
    to assume that any VLAN-tagged traffic they transmit will
    have the vlan information in the vlan_tci and not in the vlan
    header already in the skb. When transmitting skbs that already
    have tagged data with partial checksum set, the checksum doesn't
    appear to be updated correctly by the card thus resulting in a
    failure to establish TCP connections.

    The following is a packet trace taken on the receiver where a
    sender is a VM with a VLAN configued. The host VM is running on
    doest not have VLAN support and the outging interface on the
    host is tg3:
    10:12:43.503055 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
    (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27243,
    offset 0, flags [DF], proto TCP (6), length 60)
    10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect
    -> 0x48d9), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
    4294837885 ecr 0,nop,wscale 7], length 0
    10:12:44.505556 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
    (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27244,
    offset 0, flags [DF], proto TCP (6), length 60)
    10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect
    -> 0x44ee), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
    4294838888 ecr 0,nop,wscale 7], length 0

    This connection finally times out.

    I've only access to the TG3 hardware in this configuration thus have
    only tested this with TG3 driver. There are a lot of other drivers
    that do not permit user changes to vlan acceleration features, and
    I don't know if they all suffere from a similar issue.

    The patch attempt to fix this another way. It moves the vlan header
    stipping code out of the vlan module and always builds it into the
    kernel network core. This way, even if vlan is not supported on
    a virtualizatoin host, the virtual machines running on top of such
    host will still work with VLANs enabled.

    CC: Patrick McHardy
    CC: Nithin Nayak Sujir
    CC: Michael Chan
    CC: Jiri Pirko
    Signed-off-by: Vladislav Yasevich
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

30 Jul, 2014

1 commit


17 Jul, 2014

1 commit


16 Jul, 2014

1 commit

  • Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
    all users to pass NET_NAME_UNKNOWN.

    Coccinelle patch:

    @@
    expression sizeof_priv, name, setup, txqs, rxqs, count;
    @@

    (
    -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
    +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
    |
    -alloc_netdev_mq(sizeof_priv, name, setup, count)
    +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
    |
    -alloc_netdev(sizeof_priv, name, setup)
    +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
    )

    v9: move comments here from the wrong commit

    Signed-off-by: Tom Gundersen
    Reviewed-by: David Herrmann
    Signed-off-by: David S. Miller

    Tom Gundersen
     

08 Jul, 2014

1 commit


03 Jul, 2014

1 commit

  • Madalin-Cristian reported crashs happening after a recent commit
    (5a4ae5f6e7d4 "vlan: unnecessary to check if vlan_pcpu_stats is NULL")

    -----------------------------------------------------------------------
    root@p5040ds:~# vconfig add eth8 1
    root@p5040ds:~# vconfig rem eth8.1
    Unable to handle kernel paging request for data at address 0x2bc88028
    Faulting instruction address: 0xc058e950
    Oops: Kernel access of bad area, sig: 11 [#1]
    SMP NR_CPUS=8 CoreNet Generic
    Modules linked in:
    CPU: 3 PID: 2167 Comm: vconfig Tainted: G W 3.16.0-rc3-00346-g65e85bf #2
    task: e7264d90 ti: e2c2c000 task.ti: e2c2c000
    NIP: c058e950 LR: c058ea30 CTR: c058e900
    REGS: e2c2db20 TRAP: 0300 Tainted: G W (3.16.0-rc3-00346-g65e85bf)
    MSR: 00029002 CR: 48000428 XER: 20000000
    DEAR: 2bc88028 ESR: 00000000
    GPR00: c047299c e2c2dbd0 e7264d90 00000000 2bc88000 00000000 ffffffff 00000000
    GPR08: 0000000f 00000000 000000ff 00000000 28000422 10121928 10100000 10100000
    GPR16: 10100000 00000000 c07c5968 00000000 00000000 00000000 e2c2dc48 e7838000
    GPR24: c07c5bac c07c58a8 e77290cc c07b0000 00000000 c05de6c0 e7838000 e2c2dc48
    NIP [c058e950] vlan_dev_get_stats64+0x50/0x170
    LR [c058ea30] vlan_dev_get_stats64+0x130/0x170
    Call Trace:
    [e2c2dbd0] [ffffffea] 0xffffffea (unreliable)
    [e2c2dc20] [c047299c] dev_get_stats+0x4c/0x140
    [e2c2dc40] [c0488ca8] rtnl_fill_ifinfo+0x3d8/0x960
    [e2c2dd70] [c0489f4c] rtmsg_ifinfo+0x6c/0x110
    [e2c2dd90] [c04731d4] rollback_registered_many+0x344/0x3b0
    [e2c2ddd0] [c047332c] rollback_registered+0x2c/0x50
    [e2c2ddf0] [c0476058] unregister_netdevice_queue+0x78/0xf0
    [e2c2de00] [c058d800] unregister_vlan_dev+0xc0/0x160
    [e2c2de20] [c058e360] vlan_ioctl_handler+0x1c0/0x550
    [e2c2de90] [c045d11c] sock_ioctl+0x28c/0x2f0
    [e2c2deb0] [c010d070] do_vfs_ioctl+0x90/0x7b0
    [e2c2df20] [c010d7d0] SyS_ioctl+0x40/0x80
    [e2c2df40] [c000f924] ret_from_syscall+0x0/0x3c

    Fix this problem by freeing percpu stats from dev->destructor() instead
    of ndo_uninit()

    Reported-by: Madalin-Cristian Bucur
    Signed-off-by: Eric Dumazet
    Tested-by: Madalin-Cristian Bucur
    Fixes: 5a4ae5f6e7d4 ("vlan: unnecessary to check if vlan_pcpu_stats is NULL")
    Cc: Li RongQing
    Signed-off-by: David S. Miller

    Eric Dumazet
     

22 Jun, 2014

1 commit

  • skb_cow called in vlan_reorder_header does not free the skb when it failed,
    and vlan_reorder_header returns NULL to reset original skb when it is called
    in vlan_untag, lead to a memory leak.

    Signed-off-by: Li RongQing
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Li RongQing
     

24 May, 2014

1 commit

  • Conflicts:
    drivers/net/bonding/bond_alb.c
    drivers/net/ethernet/altera/altera_msgdma.c
    drivers/net/ethernet/altera/altera_sgdma.c
    net/ipv6/xfrm6_output.c

    Several cases of overlapping changes.

    The xfrm6_output.c has a bug fix which overlaps the renaming
    of skb->local_df to skb->ignore_df.

    In the Altera TSE driver cases, the register access cleanups
    in net-next overlapped with bug fixes done in net.

    Similarly a bug fix to send ALB packets in the bonding driver using
    the right source address overlaps with cleanups in net-next.

    Signed-off-by: David S. Miller

    David S. Miller
     

23 May, 2014

1 commit

  • When combining real_dev's features and vlan_features, simple
    bitwise AND is used. This doesn't work well for checksum
    offloading features as if one set has NETIF_F_HW_CSUM and the
    other NETIF_F_IP_CSUM and/or NETIF_F_IPV6_CSUM, we end up with
    no checksum offloading. However, from the logical point of view
    (how can_checksum_protocol() works), NETIF_F_HW_CSUM contains
    the functionality of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM so
    that the result should be IP/IPV6.

    Add helper function netdev_intersect_features() implementing
    this logic and use it in vlan_dev_fix_features().

    Signed-off-by: Michal Kubecek
    Signed-off-by: David S. Miller

    Michal Kubeček
     

17 May, 2014

1 commit

  • This reverts commit dc8eaaa006350d24030502a4521542e74b5cb39f.
    vlan: Fix lockdep warning when vlan dev handle notification

    Instead we use the new new API to find the lock subclass of
    our vlan device. This way we can support configurations where
    vlans are interspersed with other devices:
    bond -> vlan -> macvlan -> vlan

    Signed-off-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

13 May, 2014

1 commit


23 Apr, 2014

1 commit


19 Apr, 2014

1 commit

  • When I open the LOCKDEP config and run these steps:

    modprobe 8021q
    vconfig add eth2 20
    vconfig add eth2.20 30
    ifconfig eth2 xx.xx.xx.xx

    then the Call Trace happened:

    [32524.386288] =============================================
    [32524.386293] [ INFO: possible recursive locking detected ]
    [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G O
    [32524.386302] ---------------------------------------------
    [32524.386306] ifconfig/3103 is trying to acquire lock:
    [32524.386310] (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_mc_sync+0x64/0xb0
    [32524.386326]
    [32524.386326] but task is already holding lock:
    [32524.386330] (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40
    [32524.386341]
    [32524.386341] other info that might help us debug this:
    [32524.386345] Possible unsafe locking scenario:
    [32524.386345]
    [32524.386350] CPU0
    [32524.386352] ----
    [32524.386354] lock(&vlan_netdev_addr_lock_key/1);
    [32524.386359] lock(&vlan_netdev_addr_lock_key/1);
    [32524.386364]
    [32524.386364] *** DEADLOCK ***
    [32524.386364]
    [32524.386368] May be due to missing lock nesting notation
    [32524.386368]
    [32524.386373] 2 locks held by ifconfig/3103:
    [32524.386376] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
    [32524.386387] #1: (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40
    [32524.386398]
    [32524.386398] stack backtrace:
    [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G O 3.14.0-rc2-0.7-default+ #35
    [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [32524.386414] ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
    [32524.386421] ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
    [32524.386428] 000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
    [32524.386435] Call Trace:
    [32524.386441] [] dump_stack+0x6a/0x78
    [32524.386448] [] __lock_acquire+0x7ab/0x1940
    [32524.386454] [] ? __lock_acquire+0x3ea/0x1940
    [32524.386459] [] lock_acquire+0xe4/0x110
    [32524.386464] [] ? dev_mc_sync+0x64/0xb0
    [32524.386471] [] _raw_spin_lock_nested+0x2a/0x40
    [32524.386476] [] ? dev_mc_sync+0x64/0xb0
    [32524.386481] [] dev_mc_sync+0x64/0xb0
    [32524.386489] [] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
    [32524.386495] [] __dev_set_rx_mode+0x5f/0xb0
    [32524.386500] [] dev_set_rx_mode+0x2b/0x40
    [32524.386506] [] __dev_open+0xef/0x150
    [32524.386511] [] __dev_change_flags+0xa7/0x190
    [32524.386516] [] dev_change_flags+0x32/0x80
    [32524.386524] [] devinet_ioctl+0x7d6/0x830
    [32524.386532] [] ? dev_ioctl+0x34b/0x660
    [32524.386540] [] inet_ioctl+0x80/0xa0
    [32524.386550] [] sock_do_ioctl+0x2d/0x60
    [32524.386558] [] sock_ioctl+0x82/0x2a0
    [32524.386568] [] do_vfs_ioctl+0x93/0x590
    [32524.386578] [] ? rcu_read_lock_held+0x45/0x50
    [32524.386586] [] ? __fget_light+0x105/0x110
    [32524.386594] [] SyS_ioctl+0x91/0xb0
    [32524.386604] [] system_call_fastpath+0x16/0x1b

    ========================================================================

    The reason is that all of the addr_lock_key for vlan dev have the same class,
    so if we change the status for vlan dev, the vlan dev and its real dev will
    hold the same class of addr_lock_key together, so the warning happened.

    we should distinguish the lock depth for vlan dev and its real dev.

    v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
    could support to add 8 vlan id on a same vlan dev, I think it is enough for current
    scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
    and the vlan dev would not meet the same class key with its real dev.

    The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
    dev could get a suitable class key.

    v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
    and its real dev, but it make no sense, because the difference for subclass in the
    lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
    to distinguish the different depth for every vlan dev, the same depth of the vlan dev
    could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
    I think it is enough here, the lockdep should never exceed that value.

    v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
    we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
    and use the depth as the subclass for addr_lock_key.

    Signed-off-by: Ding Tianhong
    Signed-off-by: David S. Miller

    dingtianhong
     

30 Mar, 2014

2 commits

  • Conflicts:
    drivers/net/ethernet/marvell/mvneta.c

    The mvneta.c conflict is a case of overlapping changes,
    a conversion to devm_ioremap_resource() vs. a conversion
    to netdev_alloc_pcpu_stats.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • The gfp parameter was added in:
    commit 47be03a28cc6c80e3aa2b3e8ed6d960ff0c5c0af
    Author: Amerigo Wang
    Date: Fri Aug 10 01:24:37 2012 +0000

    netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()

    slave_enable_netpoll() and __netpoll_setup() may be called
    with read_lock() held, so should use GFP_ATOMIC to allocate
    memory. Eric suggested to pass gfp flags to __netpoll_setup().

    Cc: Eric Dumazet
    Cc: "David S. Miller"
    Reported-by: Dan Carpenter
    Signed-off-by: Eric Dumazet
    Signed-off-by: Cong Wang
    Signed-off-by: David S. Miller

    The reason for the gfp parameter was removed in:
    commit c4cdef9b7183159c23c7302aaf270d64c549f557
    Author: dingtianhong
    Date: Tue Jul 23 15:25:27 2013 +0800

    bonding: don't call slave_xxx_netpoll under spinlocks

    The slave_xxx_netpoll will call synchronize_rcu_bh(),
    so the function may schedule and sleep, it should't be
    called under spinlocks.

    bond_netpoll_setup() and bond_netpoll_cleanup() are always
    protected by rtnl lock, it is no need to take the read lock,
    as the slave list couldn't be changed outside rtnl lock.

    Signed-off-by: Ding Tianhong
    Cc: Jay Vosburgh
    Cc: Andy Gospodarek
    Signed-off-by: David S. Miller

    Nothing else that calls __netpoll_setup or ndo_netpoll_setup
    requires a gfp paramter, so remove the gfp parameter from both
    of these functions making the code clearer.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: David S. Miller

    Eric W. Biederman
     

29 Mar, 2014

1 commit


28 Mar, 2014

1 commit

  • Currently, if the card supports CTAG acceleration we do not
    account for the vlan header even if we are configuring an
    8021AD vlan. This may not be best since we'll do software
    tagging for 8021AD which will cause data copy on skb head expansion
    Configure the length based on available hw offload capabilities and
    vlan protocol.

    CC: Patrick McHardy
    Signed-off-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

27 Mar, 2014

1 commit


15 Mar, 2014

2 commits


13 Mar, 2014

1 commit


11 Mar, 2014

1 commit

  • With TX VLAN offload enabled the source MAC address for frames sent using the
    VLAN interface is currently set to the address of the real interface. This is
    wrong since the VLAN interface may be configured with a different address.

    The bug was introduced in commit 2205369a314e12fcec4781cc73ac9c08fc2b47de
    ("vlan: Fix header ops passthru when doing TX VLAN offload.").

    This patch sets the source address before calling the create function of the
    real interface.

    Signed-off-by: Peter Boström
    Signed-off-by: David S. Miller

    Peter Boström
     

10 Mar, 2014

2 commits

  • Ether_addr_equal_64bits is more efficient than ether_addr_equal, and
    can be used when each argument is an array within a structure that
    contains at least two bytes of data beyond the array, so it is safe
    to use it for vlan, and make sense for fast path.

    Cc: Joe Perches
    Cc: Patrick McHardy
    Cc: David S. Miller
    Signed-off-by: Ding Tianhong
    Signed-off-by: David S. Miller

    dingtianhong
     
  • According Joe's suggestion, maybe it'd be faster to add an unlikely to
    the test for PCKET_OTHERHOST, so I add it and see whether the performance
    could be better, although the differences is so small and negligible, but
    it is hard to catch that any lower device would set the skb type to
    PACKET_OTHERHOST, so most of time, I think it make sense to add unlikely
    for the test.

    Cc: Joe Perches
    Cc: Patrick McHardy
    Cc: David S. Miller
    Signed-off-by: Ding Tianhong
    Signed-off-by: David S. Miller

    dingtianhong
     

15 Feb, 2014

1 commit


22 Jan, 2014

2 commits


01 Jan, 2014

1 commit

  • When the vlan code detects that the real device can do TX VLAN offloads
    in hardware, it tries to arrange for the real device's header_ops to
    be invoked directly.

    But it does so illegally, by simply hooking the real device's
    header_ops up to the VLAN device.

    This doesn't work because we will end up invoking a set of header_ops
    routines which expect a device type which matches the real device, but
    will see a VLAN device instead.

    Fix this by providing a pass-thru set of header_ops which will arrange
    to pass the proper real device instead.

    To facilitate this add a dev_rebuild_header(). There are
    implementations which provide a ->cache and ->create but not a
    ->rebuild (f.e. PLIP). So we need a helper function just like
    dev_hard_header() to avoid crashes.

    Use this helper in the one existing place where the
    header_ops->rebuild was being invoked, the neighbour code.

    With lots of help from Florian Westphal.

    Signed-off-by: David S. Miller

    David S. Miller
     

14 Nov, 2013

1 commit

  • Pull core locking changes from Ingo Molnar:
    "The biggest changes:

    - add lockdep support for seqcount/seqlocks structures, this
    unearthed both bugs and required extra annotation.

    - move the various kernel locking primitives to the new
    kernel/locking/ directory"

    * 'core-locking-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits)
    block: Use u64_stats_init() to initialize seqcounts
    locking/lockdep: Mark __lockdep_count_forward_deps() as static
    lockdep/proc: Fix lock-time avg computation
    locking/doc: Update references to kernel/mutex.c
    ipv6: Fix possible ipv6 seqlock deadlock
    cpuset: Fix potential deadlock w/ set_mems_allowed
    seqcount: Add lockdep functionality to seqcount/seqlock structures
    net: Explicitly initialize u64_stats_sync structures for lockdep
    locking: Move the percpu-rwsem code to kernel/locking/
    locking: Move the lglocks code to kernel/locking/
    locking: Move the rwsem code to kernel/locking/
    locking: Move the rtmutex code to kernel/locking/
    locking: Move the semaphore core to kernel/locking/
    locking: Move the spinlock code to kernel/locking/
    locking: Move the lockdep code to kernel/locking/
    locking: Move the mutex code to kernel/locking/
    hung_task debugging: Add tracepoint to report the hang
    x86/locking/kconfig: Update paravirt spinlock Kconfig description
    lockstat: Report avg wait and hold times
    lockdep, x86/alternatives: Drop ancient lockdep fixup message
    ...

    Linus Torvalds
     

11 Nov, 2013

1 commit


08 Nov, 2013

1 commit

  • Provide a method for read-only access to the vlan device egress mapping.

    Do this by refactoring vlan_dev_get_egress_qos_mask() such that now it
    receives as an argument the skb priority instead of pointer to the skb.

    Such an access is needed for the IBoE stack where the control plane
    goes through the network stack. This is an add-on step on top of commit
    d4a968658c "net/route: export symbol ip_tos2prio" which allowed the RDMA-CM
    to use ip_tos2prio.

    Signed-off-by: Eyal Perry
    Signed-off-by: Hadar Hen Zion
    Signed-off-by: David S. Miller

    Eyal Perry
     

06 Nov, 2013

1 commit

  • In order to enable lockdep on seqcount/seqlock structures, we
    must explicitly initialize any locks.

    The u64_stats_sync structure, uses a seqcount, and thus we need
    to introduce a u64_stats_init() function and use it to initialize
    the structure.

    This unfortunately adds a lot of fairly trivial initialization code
    to a number of drivers. But the benefit of ensuring correctness makes
    this worth while.

    Because these changes are required for lockdep to be enabled, and the
    changes are quite trivial, I've not yet split this patch out into 30-some
    separate patches, as I figured it would be better to get the various
    maintainers thoughts on how to best merge this change along with
    the seqcount lockdep enablement.

    Feedback would be appreciated!

    Signed-off-by: John Stultz
    Acked-by: Julian Anastasov
    Signed-off-by: Peter Zijlstra
    Cc: Alexey Kuznetsov
    Cc: "David S. Miller"
    Cc: Eric Dumazet
    Cc: Hideaki YOSHIFUJI
    Cc: James Morris
    Cc: Jesse Gross
    Cc: Mathieu Desnoyers
    Cc: "Michael S. Tsirkin"
    Cc: Mirko Lindner
    Cc: Patrick McHardy
    Cc: Roger Luethi
    Cc: Rusty Russell
    Cc: Simon Horman
    Cc: Stephen Hemminger
    Cc: Steven Rostedt
    Cc: Thomas Petazzoni
    Cc: Wensong Zhang
    Cc: netdev@vger.kernel.org
    Link: http://lkml.kernel.org/r/1381186321-4906-2-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    John Stultz
     

20 Oct, 2013

1 commit


09 Oct, 2013

2 commits


27 Sep, 2013

1 commit

  • On netdev unregister we're removing also all of its sysfs-associated stuff,
    including the sysfs symlinks that are controlled by netdev neighbour code.
    Also, it's a subtle race condition - cause we can still access it after
    unregistering.

    Move the unlinking right before the unregistering to fix both.

    CC: Patrick McHardy
    CC: "David S. Miller"
    Signed-off-by: Veaceslav Falico
    Signed-off-by: David S. Miller

    Veaceslav Falico