1. 17 7月, 2008 10 次提交
  2. 15 7月, 2008 8 次提交
    • P
      f66ac03d
    • P
      903fc196
    • P
      dcfc23ca
    • P
      mib: add struct net to ICMP_INC_STATS · 75c939bb
      Pavel Emelyanov 提交于
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75c939bb
    • P
      inet: toss struct net initialization around · fd54d716
      Pavel Emelyanov 提交于
      Some places, that deal with ICMP statistics already have where
      to get a struct net from, but use it directly, without declaring
      a separate variable on the stack.
      
      Since I will need this net soon, I declare a struct net on the
      stack and use it in the existing places in a separate patch not
      to spoil the future ones.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd54d716
    • P
      icmp: add struct net argument to icmp_out_count · 0388b004
      Pavel Emelyanov 提交于
      This routine deals with ICMP statistics, but doesn't have a
      struct net at hands, so add one.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0388b004
    • 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
  3. 11 7月, 2008 2 次提交
  4. 10 7月, 2008 1 次提交
  5. 08 7月, 2008 2 次提交
  6. 06 7月, 2008 11 次提交
  7. 03 7月, 2008 4 次提交
  8. 02 7月, 2008 1 次提交
  9. 28 6月, 2008 1 次提交
    • E
      net/inet_lro: remove setting skb->ip_summed when not LRO-able · 251a4b32
      Eli Cohen 提交于
      When an SKB cannot be chained to a session, the current code attempts
      to "restore" its ip_summed field from lro_mgr->ip_summed. However,
      lro_mgr->ip_summed does not hold the original value; in fact, we'd
      better not touch skb->ip_summed since it is not modified by the code
      in the path leading to a failure to chain it.  Also use a cleaer
      comment to the describe the ip_summed field of struct net_lro_mgr.
      
      Issue raised by Or Gerlitz <ogerlitz@voltaire.com>
      Signed-off-by: NEli Cohen <eli@mellanox.co.il>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      251a4b32