1. 22 8月, 2007 4 次提交
    • J
      [IRDA]: Avoid a label defined but not used warning in irda_init() · 2c20d72a
      Jesper Juhl 提交于
      Easily avoidable compiler warnings bug me.
      
      Building irmod without CONFIG_SYSCTL currently results in :
       net/irda/irmod.c:132: warning: label 'out_err_2' defined but not used
      
      But that can easily be avoided by simply moving the label inside
      the existing "#ifdef CONFIG_SYSCTL" one line above it.
      
      This patch moves the label and buys us one less warning with no
      ill effects.
      Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c20d72a
    • 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
  2. 20 8月, 2007 1 次提交
  3. 16 8月, 2007 2 次提交
  4. 15 8月, 2007 12 次提交
  5. 14 8月, 2007 12 次提交
  6. 08 8月, 2007 9 次提交