1. 22 Aug, 2007 8 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>
      22117ea4
    • Konstantin Sharlaimov's avatar
      [PPP]: Fix output buffer size in ppp_decompress_frame(). · 06c7af56
      Konstantin Sharlaimov authored
      This patch addresses the issue with "osize too small" errors in mppe
      encryption.  The patch fixes the issue with wrong output buffer size
      being passed to ppp decompression routine.
      
      --------------------
      As pointed out by Suresh Mahalingam, the issue addressed by
      ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet.
      The size of allocated output buffer is correct, however it size passed to
      ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that.
      --------------------
      Signed-off-by: default avatarKonstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06c7af56
    • 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>
      2c20d72a
    • 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:
      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: 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>
      8984e41d
    • 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>
      d92a7db7
    • 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>
      39dad26c
    • Robin Getz's avatar
      fix - ensure we don't use bootconsoles after init has been released · cb00e99c
      Robin Getz authored
      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: default avatarRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cb00e99c
    • Kumar Gala's avatar
      [POWERPC] Fix PCI Device ID for MPC8544/8533 processors · 15f6ddc7
      Kumar Gala authored
      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: default avatarKumar Gala <galak@kernel.crashing.org>
      15f6ddc7
  2. 21 Aug, 2007 10 commits
  3. 20 Aug, 2007 21 commits
  4. 19 Aug, 2007 1 commit