1. 27 8月, 2008 2 次提交
  2. 23 8月, 2008 3 次提交
  3. 19 8月, 2008 4 次提交
  4. 16 8月, 2008 1 次提交
    • H
      ipv4: Disable route secret interval on zero interval · c6153b5b
      Herbert Xu 提交于
      Let me first state that disabling the route cache hash rebuild
      should not be done without extensive analysis on the risk profile
      and careful deliberation.
      
      However, there are times when this can be done safely or for
      testing.  For example, when you have mechanisms for ensuring
      that offending parties do not exist in your network.
      
      This patch lets the user disable the rebuild if the interval is
      set to zero.  This also incidentally fixes a divide-by-zero error
      with name-spaces.
      
      In addition, this patch makes the effect of an interval change
      immediate rather than it taking effect at the next rebuild as
      is currently the case.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6153b5b
  5. 15 8月, 2008 4 次提交
  6. 14 8月, 2008 1 次提交
    • D
      netns: Fix crash by making igmp per namespace · 877acedc
      Daniel Lezcano 提交于
      This patch makes the multicast socket to be per namespace.
      
      When a network namespace is created, other than the init_net and a
      multicast packet is received, the kernel goes to a hang or a kernel panic.
      
      How to reproduce ?
      
       * create a child network namespace
       * create a pair virtual device veth
          * ip link add type veth
       * move one side to the pair network device to the child namespace
          * ip link set netns <childpid> dev veth1
       * ping -I veth0 224.0.0.1
      
      The bug appears because the function ip_mc_init_dev does not initialize
      the different multicast fields as it exits because it is not the init_net.
      
      BUG: soft lockup - CPU#0 stuck for 61s! [avahi-daemon:2695]
      Modules linked in:
      irq event stamp: 50350
      hardirqs last  enabled at (50349): [<c03ee949>] _spin_unlock_irqrestore+0x34/0x39
      hardirqs last disabled at (50350): [<c03ec639>] schedule+0x9f/0x5ff
      softirqs last  enabled at (45712): [<c0374d4b>] ip_setsockopt+0x8e7/0x909
      softirqs last disabled at (45710): [<c03ee682>] _spin_lock_bh+0x8/0x27
      
      Pid: 2695, comm: avahi-daemon Not tainted (2.6.27-rc2-00029-g0872073 #3)
      EIP: 0060:[<c03ee47c>] EFLAGS: 00000297 CPU: 0
      EIP is at __read_lock_failed+0x8/0x10
      EAX: c4f38810 EBX: c4f38810 ECX: 00000000 EDX: c04cc22e
      ESI: fb0000e0 EDI: 00000011 EBP: 0f02000a ESP: c4e3faa0
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      CR0: 8005003b CR2: 44618a40 CR3: 04e37000 CR4: 000006d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
       [<c02311f8>] ? _raw_read_lock+0x23/0x25
       [<c0390666>] ? ip_check_mc+0x1c/0x83
       [<c036d478>] ? ip_route_input+0x229/0xe92
       [<c022e2e4>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c0104c9c>] ? do_IRQ+0x69/0x7d
       [<c0102e64>] ? restore_nocheck_notrace+0x0/0xe
       [<c036fdba>] ? ip_rcv+0x227/0x505
       [<c0358764>] ? netif_receive_skb+0xfe/0x2b3
       [<c03588d2>] ? netif_receive_skb+0x26c/0x2b3
       [<c035af31>] ? process_backlog+0x73/0xbd
       [<c035a8cd>] ? net_rx_action+0xc1/0x1ae
       [<c01218a8>] ? __do_softirq+0x7b/0xef
       [<c0121953>] ? do_softirq+0x37/0x4d
       [<c035b50d>] ? dev_queue_xmit+0x3d4/0x40b
       [<c0122037>] ? local_bh_enable+0x96/0xab
       [<c035b50d>] ? dev_queue_xmit+0x3d4/0x40b
       [<c012181e>] ? _local_bh_enable+0x79/0x88
       [<c035fcb8>] ? neigh_resolve_output+0x20f/0x239
       [<c0373118>] ? ip_finish_output+0x1df/0x209
       [<c0373364>] ? ip_dev_loopback_xmit+0x62/0x66
       [<c0371db5>] ? ip_local_out+0x15/0x17
       [<c0372013>] ? ip_push_pending_frames+0x25c/0x2bb
       [<c03891b8>] ? udp_push_pending_frames+0x2bb/0x30e
       [<c038a189>] ? udp_sendmsg+0x413/0x51d
       [<c038a1a9>] ? udp_sendmsg+0x433/0x51d
       [<c038f927>] ? inet_sendmsg+0x35/0x3f
       [<c034f092>] ? sock_sendmsg+0xb8/0xd1
       [<c012d554>] ? autoremove_wake_function+0x0/0x2b
       [<c022e6de>] ? copy_from_user+0x32/0x5e
       [<c022e6de>] ? copy_from_user+0x32/0x5e
       [<c034f238>] ? sys_sendmsg+0x18d/0x1f0
       [<c0175e90>] ? pipe_write+0x3cb/0x3d7
       [<c0170347>] ? do_sync_write+0xbe/0x105
       [<c012d554>] ? autoremove_wake_function+0x0/0x2b
       [<c03503b2>] ? sys_socketcall+0x176/0x1b0
       [<c01085ea>] ? syscall_trace_enter+0x6c/0x7b
       [<c0102e1a>] ? syscall_call+0x7/0xb
      Signed-off-by: NDaniel Lezcano <dlezcano@fr.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      877acedc
  7. 11 8月, 2008 9 次提交
  8. 09 8月, 2008 1 次提交
  9. 08 8月, 2008 1 次提交
  10. 07 8月, 2008 2 次提交
    • G
      tcp: Fix kernel panic when calling tcp_v(4/6)_md5_do_lookup · 6edafaaf
      Gui Jianfeng 提交于
      If the following packet flow happen, kernel will panic.
      MathineA			MathineB
      		SYN
      	---------------------->    
              	SYN+ACK
      	<----------------------
      		ACK(bad seq)
      	---------------------->
      When a bad seq ACK is received, tcp_v4_md5_do_lookup(skb->sk, ip_hdr(skb)->daddr))
      is finally called by tcp_v4_reqsk_send_ack(), but the first parameter(skb->sk) is 
      NULL at that moment, so kernel panic happens.
      This patch fixes this bug.
      
      OOPS output is as following:
      [  302.812793] IP: [<c05cfaa6>] tcp_v4_md5_do_lookup+0x12/0x42
      [  302.817075] Oops: 0000 [#1] SMP 
      [  302.819815] Modules linked in: ipv6 loop dm_multipath rtc_cmos rtc_core rtc_lib pcspkr pcnet32 mii i2c_piix4 parport_pc i2c_core parport ac button ata_piix libata dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
      [  302.849946] 
      [  302.851198] Pid: 0, comm: swapper Not tainted (2.6.27-rc1-guijf #5)
      [  302.855184] EIP: 0060:[<c05cfaa6>] EFLAGS: 00010296 CPU: 0
      [  302.858296] EIP is at tcp_v4_md5_do_lookup+0x12/0x42
      [  302.861027] EAX: 0000001e EBX: 00000000 ECX: 00000046 EDX: 00000046
      [  302.864867] ESI: ceb69e00 EDI: 1467a8c0 EBP: cf75f180 ESP: c0792e54
      [  302.868333]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [  302.871287] Process swapper (pid: 0, ti=c0792000 task=c0712340 task.ti=c0746000)
      [  302.875592] Stack: c06f413a 00000000 cf75f180 ceb69e00 00000000 c05d0d86 000016d0 ceac5400 
      [  302.883275]        c05d28f8 000016d0 ceb69e00 ceb69e20 681bf6e3 00001000 00000000 0a67a8c0 
      [  302.890971]        ceac5400 c04250a3 c06f413a c0792eb0 c0792edc cf59a620 cf59a620 cf59a634 
      [  302.900140] Call Trace:
      [  302.902392]  [<c05d0d86>] tcp_v4_reqsk_send_ack+0x17/0x35
      [  302.907060]  [<c05d28f8>] tcp_check_req+0x156/0x372
      [  302.910082]  [<c04250a3>] printk+0x14/0x18
      [  302.912868]  [<c05d0aa1>] tcp_v4_do_rcv+0x1d3/0x2bf
      [  302.917423]  [<c05d26be>] tcp_v4_rcv+0x563/0x5b9
      [  302.920453]  [<c05bb20f>] ip_local_deliver_finish+0xe8/0x183
      [  302.923865]  [<c05bb10a>] ip_rcv_finish+0x286/0x2a3
      [  302.928569]  [<c059e438>] dev_alloc_skb+0x11/0x25
      [  302.931563]  [<c05a211f>] netif_receive_skb+0x2d6/0x33a
      [  302.934914]  [<d0917941>] pcnet32_poll+0x333/0x680 [pcnet32]
      [  302.938735]  [<c05a3b48>] net_rx_action+0x5c/0xfe
      [  302.941792]  [<c042856b>] __do_softirq+0x5d/0xc1
      [  302.944788]  [<c042850e>] __do_softirq+0x0/0xc1
      [  302.948999]  [<c040564b>] do_softirq+0x55/0x88
      [  302.951870]  [<c04501b1>] handle_fasteoi_irq+0x0/0xa4
      [  302.954986]  [<c04284da>] irq_exit+0x35/0x69
      [  302.959081]  [<c0405717>] do_IRQ+0x99/0xae
      [  302.961896]  [<c040422b>] common_interrupt+0x23/0x28
      [  302.966279]  [<c040819d>] default_idle+0x2a/0x3d
      [  302.969212]  [<c0402552>] cpu_idle+0xb2/0xd2
      [  302.972169]  =======================
      [  302.974274] Code: fc ff 84 d2 0f 84 df fd ff ff e9 34 fe ff ff 83 c4 0c 5b 5e 5f 5d c3 90 90 57 89 d7 56 53 89 c3 50 68 3a 41 6f c0 e8 e9 55 e5 ff <8b> 93 9c 04 00 00 58 85 d2 59 74 1e 8b 72 10 31 db 31 c9 85 f6 
      [  303.011610] EIP: [<c05cfaa6>] tcp_v4_md5_do_lookup+0x12/0x42 SS:ESP 0068:c0792e54
      [  303.018360] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6edafaaf
    • D
      ipv4: Fix over-ifdeffing of ip_static_sysctl_init. · 11d46123
      David S. Miller 提交于
      Noticed by Paulius Zaleckas.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d46123
  11. 06 8月, 2008 2 次提交
  12. 04 8月, 2008 1 次提交
  13. 01 8月, 2008 3 次提交
  14. 31 7月, 2008 2 次提交
  15. 30 7月, 2008 1 次提交
  16. 28 7月, 2008 1 次提交
    • A
      missing bits of net-namespace / sysctl · eeb61f71
      Al Viro 提交于
      Piss-poor sysctl registration API strikes again, film at 11...
      
      What we really need is _pathname_ required to be present in already
      registered table, so that kernel could warn about bad order.  That's the
      next target for sysctl stuff (and generally saner and more explicit
      order of initialization of ipv[46] internals wouldn't hurt either).
      
      For the time being, here are full fixups required by ..._rotable()
      stuff; we make per-net sysctl sets descendents of "ro" one and make sure
      that sufficient skeleton is there before we start registering per-net
      sysctls.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eeb61f71
  17. 27 7月, 2008 2 次提交
    • A
      net: missing bits of net-namespace / sysctl · 6f9f489a
      Al Viro 提交于
      Piss-poor sysctl registration API strikes again, film at 11...
      What we really need is _pathname_ required to be present in
      already registered table, so that kernel could warn about bad
      order.  That's the next target for sysctl stuff (and generally
      saner and more explicit order of initialization of ipv[46]
      internals wouldn't hurt either).
      
      For the time being, here are full fixups required by ..._rotable()
      stuff; we make per-net sysctl sets descendents of "ro" one and
      make sure that sufficient skeleton is there before we start registering
      per-net sysctls.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f9f489a
    • D
      ipcomp: Fix warnings after ipcomp consolidation. · 2c3abab7
      David S. Miller 提交于
      net/ipv4/ipcomp.c: In function ‘ipcomp4_init_state’:
      net/ipv4/ipcomp.c:109: warning: unused variable ‘calg_desc’
      net/ipv4/ipcomp.c:108: warning: unused variable ‘ipcd’
      net/ipv4/ipcomp.c:107: warning: ‘err’ may be used uninitialized in this function
      net/ipv6/ipcomp6.c: In function ‘ipcomp6_init_state’:
      net/ipv6/ipcomp6.c:139: warning: unused variable ‘calg_desc’
      net/ipv6/ipcomp6.c:138: warning: unused variable ‘ipcd’
      net/ipv6/ipcomp6.c:137: warning: ‘err’ may be used uninitialized in this function
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c3abab7