1. 26 Aug, 2007 6 commits
  2. 23 Aug, 2007 2 commits
  3. 21 Aug, 2007 5 commits
    • Andy Whitcroft's avatar
      [IRDA] irda_nl_get_mode: always results in failure · 22117ea4
      Andy Whitcroft authored
      It seems an extraneous trailing ';' has slipped in to the error handling for a
      name registration failure causing the error path to trigger unconditionally.
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarSamuel Ortiz <samuel@sortiz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jesper Juhl's avatar
      [IRDA]: Avoid a label defined but not used warning in irda_init() · 2c20d72a
      Jesper Juhl authored
      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: default avatarJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Wei Yongjun's avatar
      [IPV6]: Fix kernel panic while send SCTP data with IP fragments · 8984e41d
      Wei Yongjun authored
      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:
      *pde = 00000000
      Oops: 0002 [#1]
      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:
      @@ -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),
                      left -= len;
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Herbert Xu's avatar
      [SNAP]: Check packet length before reading · d92a7db7
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Gerrit Renker's avatar
      [DCCP]: Allocation in atomic context · 39dad26c
      Gerrit Renker authored
      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: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 19 Aug, 2007 1 commit
  5. 15 Aug, 2007 2 commits
  6. 14 Aug, 2007 12 commits
  7. 13 Aug, 2007 12 commits