1. 10 7月, 2013 9 次提交
  2. 09 7月, 2013 1 次提交
  3. 07 7月, 2013 1 次提交
    • C
      bridge: fix some kernel warning in multicast timer · c7e8e8a8
      Cong Wang 提交于
      Several people reported the warning: "kernel BUG at kernel/timer.c:729!"
      and the stack trace is:
      
      	#7 [ffff880214d25c10] mod_timer+501 at ffffffff8106d905
      	#8 [ffff880214d25c50] br_multicast_del_pg.isra.20+261 at ffffffffa0731d25 [bridge]
      	#9 [ffff880214d25c80] br_multicast_disable_port+88 at ffffffffa0732948 [bridge]
      	#10 [ffff880214d25cb0] br_stp_disable_port+154 at ffffffffa072bcca [bridge]
      	#11 [ffff880214d25ce8] br_device_event+520 at ffffffffa072a4e8 [bridge]
      	#12 [ffff880214d25d18] notifier_call_chain+76 at ffffffff8164aafc
      	#13 [ffff880214d25d50] raw_notifier_call_chain+22 at ffffffff810858f6
      	#14 [ffff880214d25d60] call_netdevice_notifiers+45 at ffffffff81536aad
      	#15 [ffff880214d25d80] dev_close_many+183 at ffffffff81536d17
      	#16 [ffff880214d25dc0] rollback_registered_many+168 at ffffffff81537f68
      	#17 [ffff880214d25de8] rollback_registered+49 at ffffffff81538101
      	#18 [ffff880214d25e10] unregister_netdevice_queue+72 at ffffffff815390d8
      	#19 [ffff880214d25e30] __tun_detach+272 at ffffffffa074c2f0 [tun]
      	#20 [ffff880214d25e88] tun_chr_close+45 at ffffffffa074c4bd [tun]
      	#21 [ffff880214d25ea8] __fput+225 at ffffffff8119b1f1
      	#22 [ffff880214d25ef0] ____fput+14 at ffffffff8119b3fe
      	#23 [ffff880214d25f00] task_work_run+159 at ffffffff8107cf7f
      	#24 [ffff880214d25f30] do_notify_resume+97 at ffffffff810139e1
      	#25 [ffff880214d25f50] int_signal+18 at ffffffff8164f292
      
      this is due to I forgot to check if mp->timer is armed in
      br_multicast_del_pg(). This bug is introduced by
      commit 9f00b2e7 (bridge: only expire the mdb entry
      when query is received).
      
      Same for __br_mdb_del().
      Tested-by: Npoma <pomidorabelisima@gmail.com>
      Reported-by: NLiYonghua <809674045@qq.com>
      Reported-by: NRobert Hancock <hancockrwd@gmail.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7e8e8a8
  4. 05 7月, 2013 6 次提交
  5. 04 7月, 2013 11 次提交
  6. 03 7月, 2013 12 次提交
    • E
      net: lls fix build with allnoconfig · 419076f5
      Eliezer Tamir 提交于
      correct placeholder declarations to prevent build breakage when
      !CONFIG_NET_LL_RX_POLL
      Signed-off-by: NEliezer Tamir <eliezer.tamir@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      419076f5
    • P
      ip_tunnels: Use skb-len to PMTU check. · 23a3647b
      Pravin B Shelar 提交于
      In path mtu check, ip header total length works for gre device
      but not for gre-tap device.  Use skb len which is consistent
      for all tunneling types.  This is old bug in gre.
      This also fixes mtu calculation bug introduced by
      commit c5441932 (GRE: Refactor GRE tunneling code).
      Reported-by: NTimo Teras <timo.teras@iki.fi>
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23a3647b
    • D
      Merge branch 'l2tp_seq' · 784771e7
      David S. Miller 提交于
      James Chapman says:
      
      ====================
      L2TP data sequence numbers, if enabled, ensure in-order delivery. A
      receiver may reorder data packets, or simply drop out-of-sequence
      packets. If reordering is not enabled, the current implementation does
      not handle data packet loss correctly, which can result in a stalled
      L2TP session datapath as soon as the first packet is lost. Most L2TP
      users either disable sequence numbers or enable data packet reordering
      when sequence numbers are used to circumvent the issue. This patch
      series fixes the problem, and makes the L2TP sequence number handling
      RFC-compliant.
      
      v2 incorporates string format changes requested by sergei.shtylyov@cogentembedded.com.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      784771e7
    • J
      l2tp: make datapath resilient to packet loss when sequence numbers enabled · a0dbd822
      James Chapman 提交于
      If L2TP data sequence numbers are enabled and reordering is not
      enabled, data reception stops if a packet is lost since the kernel
      waits for a sequence number that is never resent. (When reordering is
      enabled, data reception restarts when the reorder timeout expires.) If
      no reorder timeout is set, we should count the number of in-sequence
      packets after the out-of-sequence (OOS) condition is detected, and reset
      sequence number state after a number of such packets are received.
      
      For now, the number of in-sequence packets while in OOS state which
      cause the sequence number state to be reset is hard-coded to 5. This
      could be configurable later.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0dbd822
    • J
      l2tp: make datapath sequence number support RFC-compliant · 8a1631d5
      James Chapman 提交于
      The L2TP datapath is not currently RFC-compliant when sequence numbers
      are used in L2TP data packets. According to the L2TP RFC, any received
      sequence number NR greater than or equal to the next expected NR is
      acceptable, where the "greater than or equal to" test is determined by
      the NR wrap point. This differs for L2TPv2 and L2TPv3, so add state in
      the session context to hold the max NR value and the NR window size in
      order to do the acceptable sequence number value check. These might be
      configurable later, but for now we derive it from the tunnel L2TP
      version, which determines the sequence number field size.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a1631d5
    • J
      l2tp: do data sequence number handling in a separate func · b6dc01a4
      James Chapman 提交于
      This change moves some code handling data sequence numbers into a
      separate function to avoid too much indentation. This is to prepare
      for some changes to data sequence number handling in subsequent
      patches.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6dc01a4
    • Y
      sctp: use get_unused_fd_flags(0) instead of get_unused_fd() · 8a59bd3e
      Yann Droneaud 提交于
      Macro get_unused_fd() is used to allocate a file descriptor with
      default flags. Those default flags (0) can be "unsafe":
      O_CLOEXEC must be used by default to not leak file descriptor
      across exec().
      
      Instead of macro get_unused_fd(), functions anon_inode_getfd()
      or get_unused_fd_flags() should be used with flags given by userspace.
      If not possible, flags should be set to O_CLOEXEC to provide userspace
      with a default safe behavor.
      
      In a further patch, get_unused_fd() will be removed so that
      new code start using anon_inode_getfd() or get_unused_fd_flags()
      with correct flags.
      
      This patch replaces calls to get_unused_fd() with equivalent call to
      get_unused_fd_flags(0) to preserve current behavor for existing code.
      
      The hard coded flag value (0) should be reviewed on a per-subsystem basis,
      and, if possible, set to O_CLOEXEC.
      Signed-off-by: NYann Droneaud <ydroneaud@opteya.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a59bd3e
    • G
      stmmac: dity-up and rework the driver debug levels · 83d7af64
      Giuseppe CAVALLARO 提交于
      Prior this patch, the internal debugging was based on ifdef
      and also some printk were useless because many info are exposed
      via ethtool.
      This patch remove all the ifdef defines and now we only use
      netif_msg_XXX levels.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83d7af64
    • I
      core/dev: set pkt_type after eth_type_trans() in dev_forward_skb() · 06a23fe3
      Isaku Yamahata 提交于
      The dev_forward_skb() assignment of pkt_type should be done
      after the call to eth_type_trans().
      
      ip-encapsulated packets can be handled by localhost. But skb->pkt_type
      can be PACKET_OTHERHOST when packet comes via veth into ip tunnel device.
      In that case, the packet is dropped by ip_rcv().
      Although this example uses gretap. l2tp-eth also has same issue.
      For l2tp-eth case, add dummy device for ip address and ip l2tp command.
      
      netns A |                     root netns                      | netns B
         veth<->veth=bridge=gretap <-loop back-> gretap=bridge=veth<->veth
      
      arp packet ->
      pkt_type
               BROADCAST------------>ip_rcv()------------------------>
      
                                                                   <- arp reply
                                                                      pkt_type
                                     ip_rcv()<-----------------OTHERHOST
                                     drop
      
      sample operations
        ip link add tapa type gretap remote 172.17.107.4 local 172.17.107.3
        ip link add tapb type gretap remote 172.17.107.3 local 172.17.107.4
        ip link set tapa up
        ip link set tapb up
        ip address add 172.17.107.3 dev tapa
        ip address add 172.17.107.4 dev tapb
        ip route get 172.17.107.3
        > local 172.17.107.3 dev lo  src 172.17.107.3
        >    cache <local>
        ip route get 172.17.107.4
        > local 172.17.107.4 dev lo  src 172.17.107.4
        >    cache <local>
        ip link add vetha type veth peer name vetha-peer
        ip link add vethb type veth peer name vethb-peer
        brctl addbr bra
        brctl addbr brb
        brctl addif bra tapa
        brctl addif bra vetha-peer
        brctl addif brb tapb
        brctl addif brb vethb-peer
        brctl show
        > bridge name     bridge id               STP enabled     interfaces
        > bra             8000.6ea21e758ff1       no              tapa
        >                                                         vetha-peer
        > brb             8000.420020eb92d5       no              tapb
        >                                                         vethb-peer
        ip link set vetha-peer up
        ip link set vethb-peer up
        ip link set bra up
        ip link set brb up
        ip netns add a
        ip netns add b
        ip link set vetha netns a
        ip link set vethb netns b
        ip netns exec a ip address add 10.0.0.3/24 dev vetha
        ip netns exec b ip address add 10.0.0.4/24 dev vethb
        ip netns exec a ip link set vetha up
        ip netns exec b ip link set vethb up
        ip netns exec a arping -I vetha 10.0.0.4
        ARPING 10.0.0.4 from 10.0.0.3 vetha
        ^CSent 2 probes (2 broadcast(s))
        Received 0 response(s)
      
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Hong Zhiguo <honkiko@gmail.com>
      Cc: Rami Rosen <ramirose@gmail.com>
      Cc: Tom Parkin <tparkin@katalix.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: dev@openvswitch.org
      Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06a23fe3
    • E
      net: convert lls to use time_in_range() · 1bc2774d
      Eliezer Tamir 提交于
      Time in range will fail safely if we move to a different cpu with an
      extremely large clock skew.
      Add time_in_range64() and convert lls to use it.
      
      changelog:
      v2
      - fixed double call to sched_clock in can_poll_ll
      - fixed checkpatchisms
      Signed-off-by: NEliezer Tamir <eliezer.tamir@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bc2774d
    • J
      nlmon: use standard rtnetlink link api for add/del devices · 7e6d4da8
      Jiri Pirko 提交于
      It is not nice when netdev is created right after module load and with
      some implicit name. So rather change nlmon to use standard rtnl link API.
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e6d4da8
    • H
      ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size · 75a493e6
      Hannes Frederic Sowa 提交于
      If the socket had an IPV6_MTU value set, ip6_append_data_mtu lost track
      of this when appending the second frame on a corked socket. This results
      in the following splat:
      
      [37598.993962] ------------[ cut here ]------------
      [37598.994008] kernel BUG at net/core/skbuff.c:2064!
      [37598.994008] invalid opcode: 0000 [#1] SMP
      [37598.994008] Modules linked in: tcp_lp uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media vfat fat usb_storage fuse ebtable_nat xt_CHECKSUM bridge stp llc ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat
      +nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi
      +scsi_transport_iscsi rfcomm bnep iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant arc4 iwldvm mac80211 snd_hda_intel acpi_cpufreq mperf coretemp snd_hda_codec microcode cdc_wdm cdc_acm
      [37598.994008]  snd_hwdep cdc_ether snd_seq snd_seq_device usbnet mii joydev btusb snd_pcm bluetooth i2c_i801 e1000e lpc_ich mfd_core ptp iwlwifi pps_core snd_page_alloc mei cfg80211 snd_timer thinkpad_acpi snd tpm_tis soundcore rfkill tpm tpm_bios vhost_net tun macvtap macvlan kvm_intel kvm uinput binfmt_misc
      +dm_crypt i915 i2c_algo_bit drm_kms_helper drm i2c_core wmi video
      [37598.994008] CPU 0
      [37598.994008] Pid: 27320, comm: t2 Not tainted 3.9.6-200.fc18.x86_64 #1 LENOVO 27744PG/27744PG
      [37598.994008] RIP: 0010:[<ffffffff815443a5>]  [<ffffffff815443a5>] skb_copy_and_csum_bits+0x325/0x330
      [37598.994008] RSP: 0018:ffff88003670da18  EFLAGS: 00010202
      [37598.994008] RAX: ffff88018105c018 RBX: 0000000000000004 RCX: 00000000000006c0
      [37598.994008] RDX: ffff88018105a6c0 RSI: ffff88018105a000 RDI: ffff8801e1b0aa00
      [37598.994008] RBP: ffff88003670da78 R08: 0000000000000000 R09: ffff88018105c040
      [37598.994008] R10: ffff8801e1b0aa00 R11: 0000000000000000 R12: 000000000000fff8
      [37598.994008] R13: 00000000000004fc R14: 00000000ffff0504 R15: 0000000000000000
      [37598.994008] FS:  00007f28eea59740(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
      [37598.994008] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [37598.994008] CR2: 0000003d935789e0 CR3: 00000000365cb000 CR4: 00000000000407f0
      [37598.994008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [37598.994008] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [37598.994008] Process t2 (pid: 27320, threadinfo ffff88003670c000, task ffff88022c162ee0)
      [37598.994008] Stack:
      [37598.994008]  ffff88022e098a00 ffff88020f973fc0 0000000000000008 00000000000004c8
      [37598.994008]  ffff88020f973fc0 00000000000004c4 ffff88003670da78 ffff8801e1b0a200
      [37598.994008]  0000000000000018 00000000000004c8 ffff88020f973fc0 00000000000004c4
      [37598.994008] Call Trace:
      [37598.994008]  [<ffffffff815fc21f>] ip6_append_data+0xccf/0xfe0
      [37598.994008]  [<ffffffff8158d9f0>] ? ip_copy_metadata+0x1a0/0x1a0
      [37598.994008]  [<ffffffff81661f66>] ? _raw_spin_lock_bh+0x16/0x40
      [37598.994008]  [<ffffffff8161548d>] udpv6_sendmsg+0x1ed/0xc10
      [37598.994008]  [<ffffffff812a2845>] ? sock_has_perm+0x75/0x90
      [37598.994008]  [<ffffffff815c3693>] inet_sendmsg+0x63/0xb0
      [37598.994008]  [<ffffffff812a2973>] ? selinux_socket_sendmsg+0x23/0x30
      [37598.994008]  [<ffffffff8153a450>] sock_sendmsg+0xb0/0xe0
      [37598.994008]  [<ffffffff810135d1>] ? __switch_to+0x181/0x4a0
      [37598.994008]  [<ffffffff8153d97d>] sys_sendto+0x12d/0x180
      [37598.994008]  [<ffffffff810dfb64>] ? __audit_syscall_entry+0x94/0xf0
      [37598.994008]  [<ffffffff81020ed1>] ? syscall_trace_enter+0x231/0x240
      [37598.994008]  [<ffffffff8166a7e7>] tracesys+0xdd/0xe2
      [37598.994008] Code: fe 07 00 00 48 c7 c7 04 28 a6 81 89 45 a0 4c 89 4d b8 44 89 5d a8 e8 1b ac b1 ff 44 8b 5d a8 4c 8b 4d b8 8b 45 a0 e9 cf fe ff ff <0f> 0b 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 48
      [37598.994008] RIP  [<ffffffff815443a5>] skb_copy_and_csum_bits+0x325/0x330
      [37598.994008]  RSP <ffff88003670da18>
      [37599.007323] ---[ end trace d69f6a17f8ac8eee ]---
      
      While there, also check if path mtu discovery is activated for this
      socket. The logic was adapted from ip6_append_data when first writing
      on the corked socket.
      
      This bug was introduced with commit
      0c183379 ("ipv6: fix incorrect ipsec
      fragment").
      
      v2:
      a) Replace IPV6_PMTU_DISC_DO with IPV6_PMTUDISC_PROBE.
      b) Don't pass ipv6_pinfo to ip6_append_data_mtu (suggestion by Gao
         feng, thanks!).
      c) Change mtu to unsigned int, else we get a warning about
         non-matching types because of the min()-macro type-check.
      Acked-by: NGao feng <gaofeng@cn.fujitsu.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75a493e6