1. 18 2月, 2010 1 次提交
  2. 14 11月, 2009 1 次提交
  3. 29 10月, 2009 1 次提交
  4. 19 10月, 2009 1 次提交
    • E
      inet: rename some inet_sock fields · c720c7e8
      Eric Dumazet 提交于
      In order to have better cache layouts of struct sock (separate zones
      for rx/tx paths), we need this preliminary patch.
      
      Goal is to transfert fields used at lookup time in the first
      read-mostly cache line (inside struct sock_common) and move sk_refcnt
      to a separate cache line (only written by rx path)
      
      This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr,
      sport and id fields. This allows a future patch to define these
      fields as macros, like sk_refcnt, without name clashes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c720c7e8
  5. 07 10月, 2009 1 次提交
    • I
      add vif using local interface index instead of IP · ee5e81f0
      Ilia K 提交于
      When routing daemon wants to enable forwarding of multicast traffic it
      performs something like:
      
             struct vifctl vc = {
                     .vifc_vifi  = 1,
                     .vifc_flags = 0,
                     .vifc_threshold = 1,
                     .vifc_rate_limit = 0,
                     .vifc_lcl_addr = ip, /* <--- ip address of physical
      interface, e.g. eth0 */
                     .vifc_rmt_addr.s_addr = htonl(INADDR_ANY),
               };
             setsockopt(fd, IPPROTO_IP, MRT_ADD_VIF, &vc, sizeof(vc));
      
      This leads (in the kernel) to calling  vif_add() function call which
      search the (physical) device using assigned IP address:
             dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr);
      
      The current API (struct vifctl) does not allow to specify an
      interface other way than using it's IP, and if there are more than a
      single interface with specified IP only the first one will be found.
      
      The attached patch (against 2.6.30.4) allows to specify an interface
      by its index, instead of IP address:
      
             struct vifctl vc = {
                     .vifc_vifi  = 1,
                     .vifc_flags = VIFF_USE_IFINDEX,   /* NEW */
                     .vifc_threshold = 1,
                     .vifc_rate_limit = 0,
                     .vifc_lcl_ifindex = if_nametoindex("eth0"),   /* NEW */
                     .vifc_rmt_addr.s_addr = htonl(INADDR_ANY),
               };
             setsockopt(fd, IPPROTO_IP, MRT_ADD_VIF, &vc, sizeof(vc));
      Signed-off-by: NIlia K. <mail4ilia@gmail.com>
      
      === modified file 'include/linux/mroute.h'
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee5e81f0
  6. 01 10月, 2009 1 次提交
  7. 15 9月, 2009 1 次提交
  8. 01 9月, 2009 1 次提交
  9. 06 7月, 2009 1 次提交
  10. 14 6月, 2009 1 次提交
    • T
      PIM-SM: namespace changes · 403dbb97
      Tom Goff 提交于
      IPv4:
        - make PIM register vifs netns local
        - set the netns when a PIM register vif is created
        - make PIM available in all network namespaces (if CONFIG_IP_PIMSM_V2)
          by adding the protocol handler when multicast routing is initialized
      
      IPv6:
        - make PIM register vifs netns local
        - make PIM available in all network namespaces (if CONFIG_IPV6_PIMSM_V2)
          by adding the protocol handler when multicast routing is initialized
      Signed-off-by: NTom Goff <thomas.goff@boeing.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      403dbb97
  11. 03 6月, 2009 2 次提交
  12. 07 2月, 2009 1 次提交
  13. 23 1月, 2009 9 次提交
  14. 16 12月, 2008 1 次提交
    • I
      ipmr: merge common code · b1879204
      Ilpo Järvinen 提交于
      Also removes redundant skb->len < x check which can't
      be true once pskb_may_pull(skb, x) succeeded.
      
      $ diff-funcs pim_rcv ipmr.c ipmr.c pim_rcv_v1
        --- ipmr.c:pim_rcv()
        +++ ipmr.c:pim_rcv_v1()
      @@ -1,22 +1,27 @@
      -static int pim_rcv(struct sk_buff * skb)
      +int pim_rcv_v1(struct sk_buff * skb)
       {
      -	struct pimreghdr *pim;
      +	struct igmphdr *pim;
       	struct iphdr   *encap;
       	struct net_device  *reg_dev = NULL;
      
       	if (!pskb_may_pull(skb, sizeof(*pim) + sizeof(*encap)))
       		goto drop;
      
      -	pim = (struct pimreghdr *)skb_transport_header(skb);
      -	if (pim->type != ((PIM_VERSION<<4)|(PIM_REGISTER)) ||
      -	    (pim->flags&PIM_NULL_REGISTER) ||
      -	    (ip_compute_csum((void *)pim, sizeof(*pim)) != 0 &&
      -	     csum_fold(skb_checksum(skb, 0, skb->len, 0))))
      +	pim = igmp_hdr(skb);
      +
      +	if (!mroute_do_pim ||
      +	    skb->len < sizeof(*pim) + sizeof(*encap) ||
      +	    pim->group != PIM_V1_VERSION || pim->code != PIM_V1_REGISTER)
       		goto drop;
      
      -	/* check if the inner packet is destined to mcast group */
       	encap = (struct iphdr *)(skb_transport_header(skb) +
      -				 sizeof(struct pimreghdr));
      +				 sizeof(struct igmphdr));
      +	/*
      +	   Check that:
      +	   a. packet is really destinted to a multicast group
      +	   b. packet is not a NULL-REGISTER
      +	   c. packet is not truncated
      +	 */
       	if (!ipv4_is_multicast(encap->daddr) ||
       	    encap->tot_len == 0 ||
       	    ntohs(encap->tot_len) + sizeof(*pim) > skb->len)
      @@ -40,9 +45,9 @@
       	skb->ip_summed = 0;
       	skb->pkt_type = PACKET_HOST;
       	dst_release(skb->dst);
      +	skb->dst = NULL;
       	reg_dev->stats.rx_bytes += skb->len;
       	reg_dev->stats.rx_packets++;
      -	skb->dst = NULL;
       	nf_reset(skb);
       	netif_rx(skb);
       	dev_put(reg_dev);
      
      $ codiff net/ipv4/ipmr.o.old net/ipv4/ipmr.o.new
      
      net/ipv4/ipmr.c:
        pim_rcv_v1 | -283
        pim_rcv    | -284
       2 functions changed, 567 bytes removed
      
      net/ipv4/ipmr.c:
        __pim_rcv | +307
       1 function changed, 307 bytes added
      
      net/ipv4/ipmr.o.new:
       3 functions changed, 307 bytes added, 567 bytes removed, diff: -260
      
      (Tested on x86_64).
      
      It seems that pimlen arg could be left out as well and
      eq-sizedness of structs trapped with BUILD_BUG_ON but
      I don't think that's more than a cosmetic flaw since there
      aren't that many args anyway.
      
      Compile tested.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1879204
  15. 04 12月, 2008 2 次提交
    • B
      net: /proc/net/ip_mr_cache, display Iif as a signed short · 999890b2
      Benjamin Thery 提交于
      Today, iproute2 fails to show multicast forwarding unresolved cache
      entries while scanning /proc/net/ip_mr_cache.
      
      Indeed, it expects to see -1 in 'Iif' column to identify unresolved
      entries but the kernel outputs 65535. It's a signed/unsigned issue:
      
      'Iif', the source interface, is retrieved from member mfc_parent in
      struct mfc_cache. mfc_parent is a vifi_t: unsigned short, but is
      displayed in ipmr_mfc_seq_show() as "%-3d", signed integer.
      
      In unresolevd entries, the 65535 value (0xFFFF) comes from this define:
      #define ALL_VIFS    ((vifi_t)(-1))
      
      That may explains why the guy who added support for this in iproute2
      thought a -1 should be expected.
      
      I don't know if this must be fixed in kernel or in iproute2. Who is
      right? What is the correct API? How was it designed originally?
      
      I let you decide if it should goes in the kernel or be fixed in iproute2.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      999890b2
    • B
      net: fix /proc/net/ip_mr_cache display - V2 · 1ea472e2
      Benjamin Thery 提交于
      /proc/net/ip_mr_cache and /proc/net/ip6_mr_cache displays garbage when
      showing unresolved mfc_cache entries.
      
      [root@qemu tests]# cat /proc/net/ip_mr_cache
      Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
      014C00EF 010014AC 1         10    10050        0  2:1    3:1
      024C00EF 010014AC 65535      514        2 -559067475
      
      The first line is correct. It is a resolved cache entry, 10 packets used it...
      The second line represents an unresolved entry, and the columns Pkts(4th),
      Bytes(5th) and Wrong(6th) just show garbage.
      
      In struct mfc_cache, there's an union to store data for resolved and
      unresolved cases. And what ipmr_mfc_seq_show() is printing in these 
      columns for the unresolved entries is some bytes from mfc_cache.mfc_un.res.
      Bad.
      (eg. In our case -559067475 is in fact 0xdead4ead which is the spinlock
      magic from mfc_cache.mfc_un.unres.unresolved.lock.magic).
      
      This patch replaces the garbage data written in these columns for the
      unresolved entries by '0' (zeros) which is more correct.
      This change doesn't break the ABI.
      
      Also, mfc->mfc_un.res.pkt, mfc->mfc_un.res.bytes, mfc->mfc_un.res.wrong_if
      are unsigned long.
      
      It applies on top of net-next-2.6.
      
      The patch for net-2.6 is slightly different because of the NIP6_FMT to
      %pI6 conversion that was made in the seq_printf.
      
      Changelog:
      ==========
      V2:
      * Instead of breaking the ABI by suppressing the columns that have no
        meaning for unresolved entries, fill them with 0 values.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ea472e2
  16. 21 11月, 2008 1 次提交
  17. 20 11月, 2008 2 次提交
  18. 03 11月, 2008 1 次提交
  19. 14 10月, 2008 1 次提交
  20. 20 7月, 2008 1 次提交
  21. 17 7月, 2008 1 次提交
  22. 15 7月, 2008 2 次提交
    • W
      ipv4: Fix ipmr unregister device oops · 7dc00c82
      Wang Chen 提交于
      An oops happens during device unregister.
      
      The following oops happened when I add two tunnels, which
      use a same device, and then delete one tunnel.
      Obviously deleting tunnel "A" causes device unregister, which
      send a notification, and after receiving notification, ipmr do
      unregister again for tunnel "B" which also use same device.
      That is wrong.
      After receiving notification, ipmr only needs to decrease reference
      count and don't do duplicated unregister.
      Fortunately, IPv6 side doesn't add tunnel in ip6mr, so it's clean.
      
      This patch fixs:
      - unregister device oops
      - using after dev_put()
      
      Here is the oops:
      ===
      Jul 11 15:39:29 wangchen kernel: ------------[ cut here ]------------
      Jul 11 15:39:29 wangchen kernel: kernel BUG at net/core/dev.c:3651!
      Jul 11 15:39:29 wangchen kernel: invalid opcode: 0000 [#1] 
      Jul 11 15:39:29 wangchen kernel: Modules linked in: ipip tunnel4 nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipv6 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet binfmt_misc button battery ac loop dm_mod usbhid ff_memless pcmcia firmware_class ohci1394 8139too mii ieee1394 yenta_socket rsrc_nonstatic pcmcia_core ide_cd_mod cdrom snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm i2c_i801 snd_timer snd i2c_core soundcore snd_page_alloc rng_core shpchp ehci_hcd uhci_hcd pci_hotplug intel_agp agpgart usbcore ext3 jbd ata_piix ahci libata dock edd fan thermal processor thermal_sys piix sd_mod scsi_mod ide_disk ide_core [last unloaded: freq_table]
      Jul 11 15:39:29 wangchen kernel: 
      Jul 11 15:39:29 wangchen kernel: Pid: 4102, comm: mroute Not tainted (2.6.26-rc9-default #69)
      Jul 11 15:39:29 wangchen kernel: EIP: 0060:[<c024636b>] EFLAGS: 00010202 CPU: 0
      Jul 11 15:39:29 wangchen kernel: EIP is at rollback_registered+0x61/0xe3
      Jul 11 15:39:29 wangchen kernel: EAX: 00000001 EBX: ecba6000 ECX: 00000000 EDX: ffffffff
      Jul 11 15:39:29 wangchen kernel: ESI: 00000001 EDI: ecba6000 EBP: c03de2e8 ESP: ed8e7c3c
      Jul 11 15:39:29 wangchen kernel:  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      Jul 11 15:39:29 wangchen kernel: Process mroute (pid: 4102, ti=ed8e6000 task=ed41e830 task.ti=ed8e6000)
      Jul 11 15:39:29 wangchen kernel: Stack: ecba6000 c024641c 00000028 c0284e1a 00000001 c03de2e8 ecba6000 eecff360 
      Jul 11 15:39:29 wangchen kernel:        c0284e4c c03536f4 fffffff8 00000000 c029a819 ecba6000 00000006 ecba6000 
      Jul 11 15:39:29 wangchen kernel:        00000000 ecba6000 c03de2c0 c012841b ffffffff 00000000 c024639f ecba6000 
      Jul 11 15:39:29 wangchen kernel: Call Trace:
      Jul 11 15:39:29 wangchen kernel:  [<c024641c>] unregister_netdevice+0x2f/0x51
      Jul 11 15:39:29 wangchen kernel:  [<c0284e1a>] vif_delete+0xaf/0xc3
      Jul 11 15:39:29 wangchen kernel:  [<c0284e4c>] ipmr_device_event+0x1e/0x30
      Jul 11 15:39:29 wangchen kernel:  [<c029a819>] notifier_call_chain+0x2a/0x47
      Jul 11 15:39:29 wangchen kernel:  [<c012841b>] raw_notifier_call_chain+0x9/0xc
      Jul 11 15:39:29 wangchen kernel:  [<c024639f>] rollback_registered+0x95/0xe3
      Jul 11 15:39:29 wangchen kernel:  [<c024641c>] unregister_netdevice+0x2f/0x51
      Jul 11 15:39:29 wangchen kernel:  [<c0284e1a>] vif_delete+0xaf/0xc3
      Jul 11 15:39:29 wangchen kernel:  [<c0285eee>] ip_mroute_setsockopt+0x47a/0x801
      Jul 11 15:39:29 wangchen kernel:  [<eea5a70c>] do_get_write_access+0x2df/0x313 [jbd]
      Jul 11 15:39:29 wangchen kernel:  [<c01727c4>] __find_get_block_slow+0xda/0xe4
      Jul 11 15:39:29 wangchen kernel:  [<c0172a7f>] __find_get_block+0xf8/0x122
      Jul 11 15:39:29 wangchen kernel:  [<c0172a7f>] __find_get_block+0xf8/0x122
      Jul 11 15:39:29 wangchen kernel:  [<eea5d563>] journal_cancel_revoke+0xda/0x110 [jbd]
      Jul 11 15:39:29 wangchen kernel:  [<c0263501>] ip_setsockopt+0xa9/0x9ee
      Jul 11 15:39:29 wangchen kernel:  [<eea5d563>] journal_cancel_revoke+0xda/0x110 [jbd]
      Jul 11 15:39:29 wangchen kernel:  [<eea5a70c>] do_get_write_access+0x2df/0x313 [jbd]
      Jul 11 15:39:29 wangchen kernel:  [<eea69287>] __ext3_get_inode_loc+0xcf/0x271 [ext3]
      Jul 11 15:39:29 wangchen kernel:  [<eea743c7>] __ext3_journal_dirty_metadata+0x13/0x32 [ext3]
      Jul 11 15:39:29 wangchen kernel:  [<c0116434>] __wake_up+0xf/0x15
      Jul 11 15:39:29 wangchen kernel:  [<eea5a424>] journal_stop+0x1bd/0x1c6 [jbd]
      Jul 11 15:39:29 wangchen kernel:  [<eea703a7>] __ext3_journal_stop+0x19/0x34 [ext3]
      Jul 11 15:39:29 wangchen kernel:  [<c014291e>] get_page_from_freelist+0x94/0x369
      Jul 11 15:39:29 wangchen kernel:  [<c01408f2>] filemap_fault+0x1ac/0x2fe
      Jul 11 15:39:29 wangchen kernel:  [<c01a605e>] security_sk_alloc+0xd/0xf
      Jul 11 15:39:29 wangchen kernel:  [<c023edea>] sk_prot_alloc+0x36/0x78
      Jul 11 15:39:29 wangchen kernel:  [<c0240037>] sk_alloc+0x3a/0x40
      Jul 11 15:39:29 wangchen kernel:  [<c0276062>] raw_hash_sk+0x46/0x4e
      Jul 11 15:39:29 wangchen kernel:  [<c0166aff>] d_alloc+0x1b/0x157
      Jul 11 15:39:29 wangchen kernel:  [<c023e4d1>] sock_common_setsockopt+0x12/0x16
      Jul 11 15:39:29 wangchen kernel:  [<c023cb1e>] sys_setsockopt+0x6f/0x8e
      Jul 11 15:39:29 wangchen kernel:  [<c023e105>] sys_socketcall+0x15c/0x19e
      Jul 11 15:39:29 wangchen kernel:  [<c0103611>] sysenter_past_esp+0x6a/0x99
      Jul 11 15:39:29 wangchen kernel:  [<c0290000>] unix_poll+0x69/0x78
      Jul 11 15:39:29 wangchen kernel:  =======================
      Jul 11 15:39:29 wangchen kernel: Code: 83 e0 01 00 00 85 c0 75 1f 53 53 68 12 81 31 c0 e8 3c 30 ed ff ba 3f 0e 00 00 b8 b9 7f 31 c0 83 c4 0c 5b e9 f5 26 ed ff 48 74 04 <0f> 0b eb fe 89 d8 e8 21 ff ff ff 89 d8 e8 62 ea ff ff c7 83 e0 
      Jul 11 15:39:29 wangchen kernel: EIP: [<c024636b>] rollback_registered+0x61/0xe3 SS:ESP 0068:ed8e7c3c
      Jul 11 15:39:29 wangchen kernel: ---[ end trace c311acf85d169786 ]---
      ===
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7dc00c82
    • W
      ipv4: Check return of dev_set_allmulti · d607032d
      Wang Chen 提交于
      allmulti might overflow.
      Commit: "netdevice: Fix promiscuity and allmulti overflow" in net-next makes
      dev_set_promiscuity/allmulti return error number if overflow happened.
      
      Here, we check the positive increment for allmulti to get error return.
      
      PS: For unwinding tunnel creating, we let ipip->ioctl() to handle it.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d607032d
  23. 03 7月, 2008 1 次提交
  24. 12 6月, 2008 1 次提交
  25. 22 5月, 2008 2 次提交
  26. 26 3月, 2008 2 次提交