1. 01 4月, 2015 6 次提交
    • J
      xfrm: simplify xfrm_address_t use · 15e318bd
      Jiri Benc 提交于
      In many places, the a6 field is typecasted to struct in6_addr. As the
      fields are in union anyway, just add in6_addr type to the union and
      get rid of the typecasting.
      
      Modifying the uapi header is okay, the union has still the same size.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15e318bd
    • J
      tcp: simplify inetpeer_addr_base use · 8f55db48
      Jiri Benc 提交于
      In many places, the a6 field is typecasted to struct in6_addr. As the
      fields are in union anyway, just add in6_addr type to the union and get rid
      of the typecasting.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f55db48
    • I
      ipv6: coding style: comparison for inequality with NULL · 53b24b8f
      Ian Morris 提交于
      The ipv6 code uses a mixture of coding styles. In some instances check for NULL
      pointer is done as x != NULL and sometimes as x. x is preferred according to
      checkpatch and this patch makes the code consistent by adopting the latter
      form.
      
      No changes detected by objdiff.
      Signed-off-by: NIan Morris <ipm@chirality.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53b24b8f
    • I
      ipv6: coding style: comparison for equality with NULL · 63159f29
      Ian Morris 提交于
      The ipv6 code uses a mixture of coding styles. In some instances check for NULL
      pointer is done as x == NULL and sometimes as !x. !x is preferred according to
      checkpatch and this patch makes the code consistent by adopting the latter
      form.
      
      No changes detected by objdiff.
      Signed-off-by: NIan Morris <ipm@chirality.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63159f29
    • A
      fib_trie: Cleanup ip_fib_net_exit code path · 6e47d6ca
      Alexander Duyck 提交于
      While fixing a recent issue I noticed that we are doing some unnecessary
      work inside the loop for ip_fib_net_exit.  As such I am pulling out the
      initialization to NULL for the locally stored fib_local, fib_main, and
      fib_default.
      
      In addition I am restoring the original code for flushing the table as
      there is no need to split up the fib_table_flush and hlist_del work since
      the code for packing the tnodes with multiple key vectors was dropped.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e47d6ca
    • A
      fib_trie: Fix warning on fib4_rules_exit · ad88d051
      Alexander Duyck 提交于
      This fixes the following warning:
      
       BUG: sleeping function called from invalid context at mm/slub.c:1268
       in_atomic(): 1, irqs_disabled(): 0, pid: 6, name: kworker/u8:0
       INFO: lockdep is turned off.
       CPU: 3 PID: 6 Comm: kworker/u8:0 Tainted: G        W       4.0.0-rc5+ #895
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       Workqueue: netns cleanup_net
        0000000000000006 ffff88011953fa68 ffffffff81a203b6 000000002c3a2c39
        ffff88011952a680 ffff88011953fa98 ffffffff8109daf0 ffff8801186c6aa8
        ffffffff81fbc9e5 00000000000004f4 0000000000000000 ffff88011953fac8
       Call Trace:
        [<ffffffff81a203b6>] dump_stack+0x4c/0x65
        [<ffffffff8109daf0>] ___might_sleep+0x1c3/0x1cb
        [<ffffffff8109db70>] __might_sleep+0x78/0x80
        [<ffffffff8117a60e>] slab_pre_alloc_hook+0x31/0x8f
        [<ffffffff8117d4f6>] __kmalloc+0x69/0x14e
        [<ffffffff818ed0e1>] ? kzalloc.constprop.20+0xe/0x10
        [<ffffffff818ed0e1>] kzalloc.constprop.20+0xe/0x10
        [<ffffffff818ef622>] fib_trie_table+0x27/0x8b
        [<ffffffff818ef6bd>] fib_trie_unmerge+0x37/0x2a6
        [<ffffffff810b06e1>] ? arch_local_irq_save+0x9/0xc
        [<ffffffff818e9793>] fib_unmerge+0x2d/0xb3
        [<ffffffff818f5f56>] fib4_rule_delete+0x1f/0x52
        [<ffffffff817f1c3f>] ? fib_rules_unregister+0x30/0xb2
        [<ffffffff817f1c8b>] fib_rules_unregister+0x7c/0xb2
        [<ffffffff818f64a1>] fib4_rules_exit+0x15/0x18
        [<ffffffff818e8c0a>] ip_fib_net_exit+0x23/0xf2
        [<ffffffff818e91f8>] fib_net_exit+0x32/0x36
        [<ffffffff817c8352>] ops_exit_list+0x45/0x57
        [<ffffffff817c8d3d>] cleanup_net+0x13c/0x1cd
        [<ffffffff8108b05d>] process_one_work+0x255/0x4ad
        [<ffffffff8108af69>] ? process_one_work+0x161/0x4ad
        [<ffffffff8108b4b1>] worker_thread+0x1cd/0x2ab
        [<ffffffff8108b2e4>] ? process_scheduled_works+0x2f/0x2f
        [<ffffffff81090686>] kthread+0xd4/0xdc
        [<ffffffff8109ec8f>] ? local_clock+0x19/0x22
        [<ffffffff810905b2>] ? __kthread_parkme+0x83/0x83
        [<ffffffff81a2c0c8>] ret_from_fork+0x58/0x90
        [<ffffffff810905b2>] ? __kthread_parkme+0x83/0x83
      
      The issue was that as a part of exiting the default rules were being
      deleted which resulted in the local trie being unmerged.  By moving the
      freeing of the FIB tables up we can avoid the unmerge since there is no
      local table left when we call the fib4_rules_exit function.
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Reported-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad88d051
  2. 30 3月, 2015 11 次提交
    • J
      tipc: fix two bugs in secondary destination lookup · d482994f
      Jon Paul Maloy 提交于
      A message sent to a node after a successful name table lookup may still
      find that the destination socket has disappeared, because distribution
      of name table updates is non-atomic. If so, the message will be rejected
      back to the sender with error code TIPC_ERR_NO_PORT. If the source
      socket of the message has disappeared in the meantime, the message
      should be dropped.
      
      However, in the currrent code, the message will instead be subject to an
      unwanted tertiary lookup, because the function tipc_msg_lookup_dest()
      doesn't check if there is an error code present in the message before
      performing the lookup. In the worst case, the message may now find the
      old destination again, and be redirected once more, instead of being
      dropped directly as it should be.
      
      A second bug in this function is that the "prev_node" field in the message
      is not updated after successful lookup, something that may have
      unpredictable consequences.
      
      The problems arising from those bugs occur very infrequently.
      
      The third change in this function; the test on msg_reroute_msg_cnt() is
      purely cosmetic, reflecting that the returned value never can be negative.
      
      This commit corrects the two bugs described above.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d482994f
    • T
      net: Introduce passthru_features_check · e38f3025
      Toshiaki Makita 提交于
      As there are a number of (especially virtual) devices that don't
      need the multiple vlan check, introduce passthru_features_check() for
      convenience.
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e38f3025
    • T
      net: Move check for multiple vlans to drivers · 8cb65d00
      Toshiaki Makita 提交于
      To allow drivers to handle the features check for multiple tags,
      move the check to ndo_features_check().
      As no drivers currently handle multiple tagged TSO, introduce
      dflt_features_check() and call it if the driver does not have
      ndo_features_check().
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb65d00
    • T
      vlan: Introduce helper functions to check if skb is tagged · f5a7fb88
      Toshiaki Makita 提交于
      Separate the two checks for single vlan and multiple vlans in
      netif_skb_features().  This allows us to move the check for multiple
      vlans to another function later.
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5a7fb88
    • T
      vlan: Add features for stacked vlan device · 8d463504
      Toshiaki Makita 提交于
      Stacked vlan devices curretly have few features (GRO, HIGHDMA, LLTX).
      Since we have software fallbacks in case the NIC can not handle some
      features for multiple vlans, we can add the same features as the lower
      vlan devices for stacked vlan devices.
      
      This allows stacked vlan devices to create large (GSO) packets and not to
      segment packets. Those packets will be segmented by software on the real
      device, or even can be segmented by the NIC once TSO for multiple vlans
      becomes enabled by the following patches.
      
      The exception is those related to FCoE, which does not have a software
      fallback.
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d463504
    • A
      tc: bpf: generalize pedit action · 608cd71a
      Alexei Starovoitov 提交于
      existing TC action 'pedit' can munge any bits of the packet.
      Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
      bpf_skb_store_bytes() helper function.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Reviewed-by: NJiri Pirko <jiri@resnulli.us>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      608cd71a
    • G
      net: dsa: Add basic framework to support ndo_fdb functions · 339d8262
      Guenter Roeck 提交于
      Provide callbacks for ndo_fdb_add, ndo_fdb_del, and ndo_fdb_dump.
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      339d8262
    • Y
      tipc: involve reference counter for node structure · 8a0f6ebe
      Ying Xue 提交于
      TIPC node hash node table is protected with rcu lock on read side.
      tipc_node_find() is used to look for a node object with node address
      through iterating the hash node table. As the entire process of what
      tipc_node_find() traverses the table is guarded with rcu read lock,
      it's safe for us. However, when callers use the node object returned
      by tipc_node_find(), there is no rcu read lock applied. Therefore,
      this is absolutely unsafe for callers of tipc_node_find().
      
      Now we introduce a reference counter for node structure. Before
      tipc_node_find() returns node object to its caller, it first increases
      the reference counter. Accordingly, after its caller used it up,
      it decreases the counter again. This can prevent a node being used by
      one thread from being freed by another thread.
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericson.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a0f6ebe
    • Y
      tipc: fix potential deadlock when all links are reset · b952b2be
      Ying Xue 提交于
      [   60.988363] ======================================================
      [   60.988754] [ INFO: possible circular locking dependency detected ]
      [   60.989152] 3.19.0+ #194 Not tainted
      [   60.989377] -------------------------------------------------------
      [   60.989781] swapper/3/0 is trying to acquire lock:
      [   60.990079]  (&(&n_ptr->lock)->rlock){+.-...}, at: [<ffffffffa0006dca>] tipc_link_retransmit+0x1aa/0x240 [tipc]
      [   60.990743]
      [   60.990743] but task is already holding lock:
      [   60.991106]  (&(&bclink->lock)->rlock){+.-...}, at: [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
      [   60.991738]
      [   60.991738] which lock already depends on the new lock.
      [   60.991738]
      [   60.992174]
      [   60.992174] the existing dependency chain (in reverse order) is:
      [   60.992174]
      -> #1 (&(&bclink->lock)->rlock){+.-...}:
      [   60.992174]        [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
      [   60.992174]        [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
      [   60.992174]        [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
      [   60.992174]        [<ffffffffa0000f57>] tipc_bclink_add_node+0x97/0xf0 [tipc]
      [   60.992174]        [<ffffffffa0011815>] tipc_node_link_up+0xf5/0x110 [tipc]
      [   60.992174]        [<ffffffffa0007783>] link_state_event+0x2b3/0x4f0 [tipc]
      [   60.992174]        [<ffffffffa00193c0>] tipc_link_proto_rcv+0x24c/0x418 [tipc]
      [   60.992174]        [<ffffffffa0008857>] tipc_rcv+0x827/0xac0 [tipc]
      [   60.992174]        [<ffffffffa0002ca3>] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
      [   60.992174]        [<ffffffff81646e66>] __netif_receive_skb_core+0x746/0x980
      [   60.992174]        [<ffffffff816470c1>] __netif_receive_skb+0x21/0x70
      [   60.992174]        [<ffffffff81647295>] netif_receive_skb_internal+0x35/0x130
      [   60.992174]        [<ffffffff81648218>] napi_gro_receive+0x158/0x1d0
      [   60.992174]        [<ffffffff81559e05>] e1000_clean_rx_irq+0x155/0x490
      [   60.992174]        [<ffffffff8155c1b7>] e1000_clean+0x267/0x990
      [   60.992174]        [<ffffffff81647b60>] net_rx_action+0x150/0x360
      [   60.992174]        [<ffffffff8105ec43>] __do_softirq+0x123/0x360
      [   60.992174]        [<ffffffff8105f12e>] irq_exit+0x8e/0xb0
      [   60.992174]        [<ffffffff8179f9f5>] do_IRQ+0x65/0x110
      [   60.992174]        [<ffffffff8179da6f>] ret_from_intr+0x0/0x13
      [   60.992174]        [<ffffffff8100de9f>] arch_cpu_idle+0xf/0x20
      [   60.992174]        [<ffffffff8109dfa6>] cpu_startup_entry+0x2f6/0x3f0
      [   60.992174]        [<ffffffff81033cda>] start_secondary+0x13a/0x150
      [   60.992174]
      -> #0 (&(&n_ptr->lock)->rlock){+.-...}:
      [   60.992174]        [<ffffffff810a8f7d>] __lock_acquire+0x163d/0x1ca0
      [   60.992174]        [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
      [   60.992174]        [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
      [   60.992174]        [<ffffffffa0006dca>] tipc_link_retransmit+0x1aa/0x240 [tipc]
      [   60.992174]        [<ffffffffa0001e11>] tipc_bclink_rcv+0x611/0x640 [tipc]
      [   60.992174]        [<ffffffffa0008646>] tipc_rcv+0x616/0xac0 [tipc]
      [   60.992174]        [<ffffffffa0002ca3>] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
      [   60.992174]        [<ffffffff81646e66>] __netif_receive_skb_core+0x746/0x980
      [   60.992174]        [<ffffffff816470c1>] __netif_receive_skb+0x21/0x70
      [   60.992174]        [<ffffffff81647295>] netif_receive_skb_internal+0x35/0x130
      [   60.992174]        [<ffffffff81648218>] napi_gro_receive+0x158/0x1d0
      [   60.992174]        [<ffffffff81559e05>] e1000_clean_rx_irq+0x155/0x490
      [   60.992174]        [<ffffffff8155c1b7>] e1000_clean+0x267/0x990
      [   60.992174]        [<ffffffff81647b60>] net_rx_action+0x150/0x360
      [   60.992174]        [<ffffffff8105ec43>] __do_softirq+0x123/0x360
      [   60.992174]        [<ffffffff8105f12e>] irq_exit+0x8e/0xb0
      [   60.992174]        [<ffffffff8179f9f5>] do_IRQ+0x65/0x110
      [   60.992174]        [<ffffffff8179da6f>] ret_from_intr+0x0/0x13
      [   60.992174]        [<ffffffff8100de9f>] arch_cpu_idle+0xf/0x20
      [   60.992174]        [<ffffffff8109dfa6>] cpu_startup_entry+0x2f6/0x3f0
      [   60.992174]        [<ffffffff81033cda>] start_secondary+0x13a/0x150
      [   60.992174]
      [   60.992174] other info that might help us debug this:
      [   60.992174]
      [   60.992174]  Possible unsafe locking scenario:
      [   60.992174]
      [   60.992174]        CPU0                    CPU1
      [   60.992174]        ----                    ----
      [   60.992174]   lock(&(&bclink->lock)->rlock);
      [   60.992174]                                lock(&(&n_ptr->lock)->rlock);
      [   60.992174]                                lock(&(&bclink->lock)->rlock);
      [   60.992174]   lock(&(&n_ptr->lock)->rlock);
      [   60.992174]
      [   60.992174]  *** DEADLOCK ***
      [   60.992174]
      [   60.992174] 3 locks held by swapper/3/0:
      [   60.992174]  #0:  (rcu_read_lock){......}, at: [<ffffffff81646791>] __netif_receive_skb_core+0x71/0x980
      [   60.992174]  #1:  (rcu_read_lock){......}, at: [<ffffffffa0002c35>] tipc_l2_rcv_msg+0x5/0xd0 [tipc]
      [   60.992174]  #2:  (&(&bclink->lock)->rlock){+.-...}, at: [<ffffffffa00004be>] tipc_bclink_lock+0x8e/0xa0 [tipc]
      [   60.992174]
      
      The correct the sequence of grabbing n_ptr->lock and bclink->lock
      should be that the former is first held and the latter is then taken,
      which exactly happened on CPU1. But especially when the retransmission
      of broadcast link is failed, bclink->lock is first held in
      tipc_bclink_rcv(), and n_ptr->lock is taken in link_retransmit_failure()
      called by tipc_link_retransmit() subsequently, which is demonstrated on
      CPU0. As a result, deadlock occurs.
      
      If the order of holding the two locks happening on CPU0 is reversed, the
      deadlock risk will be relieved. Therefore, the node lock taken in
      link_retransmit_failure() originally is moved to tipc_bclink_rcv()
      so that it's obtained before bclink lock. But the precondition of
      the adjustment of node lock is that responding to bclink reset event
      must be moved from tipc_bclink_unlock() to tipc_node_unlock().
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b952b2be
    • E
      tcp: tcp_syn_flood_action() can be static · 41d25fe0
      Eric Dumazet 提交于
      After commit 1fb6f159 ("tcp: add tcp_conn_request"),
      tcp_syn_flood_action() is no longer used from IPv6.
      
      We can make it static, by moving it above tcp_conn_request()
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41d25fe0
    • W
      fib6: install fib6 ops in the last step · 85b99092
      WANG Cong 提交于
      We should not commit the new ops until we finish
      all the setup, otherwise we have to NULL it on failure.
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85b99092
  3. 28 3月, 2015 1 次提交
  4. 26 3月, 2015 22 次提交