1. 22 8月, 2007 8 次提交
    • W
      [IPV6]: Fix kernel panic while send SCTP data with IP fragments · 8984e41d
      Wei Yongjun 提交于
      If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
      kernel panic will occur when SCTP DATA is send again.
      
      This is because of a bad dest address when call to skb_copy_bits().
      
      The messages sequence is like this:
      
      Endpoint A                             Endpoint B
                                     <-------  SCTP DATA (size=1432)
      ICMP6 message ------->
      (Packet Too Big pmtu=1280)
                                     <-------  Resend SCTP DATA (size=1432)
      ------------kernel panic---------------
      
       printing eip:
      c05be62a
      *pde = 00000000
      Oops: 0002 [#1]
      SMP
      Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
      CPU:    0
      EIP:    0060:[<c05be62a>]    Not tainted VLI
      EFLAGS: 00010282   (2.6.23-rc2 #1)
      EIP is at skb_copy_bits+0x4f/0x1ef
      eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
      esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
      ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
      Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
      Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
             d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
             000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
      Call Trace:
       [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f
       [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3
       [<c040608d>] show_registers+0x1b8/0x289
       [<c0406271>] die+0x113/0x246
       [<c0625dbc>] do_page_fault+0x4ad/0x57e
       [<c0624642>] error_code+0x72/0x78
       [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6]
       [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6]
       [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp]
       [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp]
       [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp]
       [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp]
       [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp]
       [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp]
       [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6]
       [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6]
       [<d09be240>] ip6_input+0x1dc/0x310 [ipv6]
       [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6]
       [<c05c3789>] netif_receive_skb+0x2d2/0x335
       [<c05c5733>] process_backlog+0x7f/0xd0
       [<c05c58f6>] net_rx_action+0x96/0x17e
       [<c042e722>] __do_softirq+0x64/0xcd
       [<c0406f37>] do_softirq+0x5c/0xac
       =======================
      Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
      EIP: [<c05be62a>] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
      Kernel panic - not syncing: Fatal exception in interrupt
      
      Arnaldo says:
      ====================
      Thanks! I'm to blame for this one, problem was introduced in:
      
      b0e380b1
      
      @@ -761,7 +762,7 @@ slow_path:
                      /*
                       *      Copy a block of the IP datagram.
                       */
      -               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
      +               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
      len))
                              BUG();
                      left -= len;
      ====================
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8984e41d
    • H
      [SNAP]: Check packet length before reading · d92a7db7
      Herbert Xu 提交于
      The snap_rcv code reads 5 bytes so we should make sure that
      we have 5 bytes in the head before proceeding.
      
      Based on diagnosis and fix by Evgeniy Polyakov, reported by
      Alan J. Wylie.
      
      Patch also kills the skb->sk assignment before kfree_skb
      since it's redundant.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d92a7db7
    • G
      [DCCP]: Allocation in atomic context · 39dad26c
      Gerrit Renker 提交于
      This fixes the following bug reported in syslog:
      
      [ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032
      [ 4039.051668] in_atomic():1, irqs_disabled():0
      [ 4039.051670] INFO: lockdep is turned off.
      [ 4039.051674]  [<c0104c0f>] show_trace_log_lvl+0x1a/0x30
      [ 4039.051687]  [<c0104d4d>] show_trace+0x12/0x14
      [ 4039.051691]  [<c0104d65>] dump_stack+0x16/0x18
      [ 4039.051695]  [<c011371e>] __might_sleep+0xaf/0xbe
      [ 4039.051700]  [<c0157b66>] __kmalloc+0xb1/0xd0
      [ 4039.051706]  [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2]
      [ 4039.051717]  [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2]
      [ 4039.051723]  [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp]
      [ 4039.051741]  [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp]
      [ 4039.051750]  [<c03907fc>] inet_sendmsg+0x2e/0x4c
      [ 4039.051758]  [<c033a47d>] sock_aio_write+0xd5/0x107
      [ 4039.051766]  [<c015abc1>] do_sync_write+0xcd/0x11c
      [ 4039.051772]  [<c015b296>] vfs_write+0x118/0x11f
      [ 4039.051840]  [<c015b932>] sys_write+0x3d/0x64
      [ 4039.051845]  [<c0103e7c>] syscall_call+0x7/0xb
      [ 4039.051848]  =======================
      
      The problem was that GFP_KERNEL was used; fixed by using gfp_any().
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39dad26c
    • R
      fix - ensure we don't use bootconsoles after init has been released · cb00e99c
      Robin Getz 提交于
      Gerd Hoffmann pointed out that my patch from yesterday can lead
      to a null pointer dereference if the kernel is booted with no
      console, and no earlyprintk defined. This fixes that issue.
      Signed-off-by: NRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb00e99c
    • K
      [POWERPC] Fix PCI Device ID for MPC8544/8533 processors · 15f6ddc7
      Kumar Gala 提交于
      The initial user manuals for MPC8544/8533 had some issues with properly
      documenting the device IDs for MPC8544/8533.  These processors are almost
      identical and both show up on the reference boards.
      
      Fix up the quirks for PCIe support to handle MPC8533/E.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      15f6ddc7
    • S
      sky2: don't clear phy power bits · f350339c
      Stephen Hemminger 提交于
      There are special PHY settings available on Yukon EC-U chip that
      should not get cleared. This should solve mysterious errors on some
      motherboards (like Gigabyte DS-3).
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f350339c
    • M
      hisax: update hfc_usb driver · d6c59c13
      Martin Bachem 提交于
      This fixes handling of USB ISO completion error -EXDEV and includes
      several other changes to current CVS version at isdn4linux.de (changes
      in debug flags, style of code remarks, etc)
      Signed-off-by: NMartin Bachem <info@colognechip.com>
      Acked-by: NKarsten Keil <kkeil@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d6c59c13
    • A
      i386: Mark NUMA support experimental · 36ce1514
      Andi Kleen 提交于
      I did some testing and found quite a lot of problems (doesn't
      boot at all on non NUMA and misassigns cores on Opteron systems).
      
      Mark it as experimental and warn against its use for now.
      
      It's still default y for SUMMIT/NUMAQ because it'll presumably
      work on these systems.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36ce1514
  2. 21 8月, 2007 20 次提交
  3. 20 8月, 2007 11 次提交
  4. 19 8月, 2007 1 次提交