Skip to content

L
linux-davinci
Switch branch/tag
  1. 22 Oct, 2006 4 commits
    • Tobias Klauser's avatar
      [ATM]: No need to return void · b45eccdb
      Tobias Klauser authored 
      The module_exit function has return-type void and pci_unregister_driver()
returns void anyway.
Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b45eccdb
    • Jeff Garzik's avatar
      [ATM]: handle sysfs errors · 97f80bc6
      Jeff Garzik authored 
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97f80bc6
    • David S. Miller's avatar
      [DCCP] ipv6: Fix opt_skb leak. · fd169f15
      David S. Miller authored 
      Based upon a patch from Jesper Juhl.  Try to match the
TCP IPv6 code this was copied from as much as possible,
so that it's easy to see where to add the ipv6 pktoptions
support code.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd169f15
    • Gerrit Renker's avatar
      [DCCP]: Fix Oops in DCCPv6 · 82709531
      Gerrit Renker authored 
      I think I got the cause for the Oops observed in
http://www.mail-archive.com/dccp@vger.kernel.org/msg00578.html

The problem is always with applications listening on PF_INET6 sockets. Apart
from the mentioned oops, I observed another one one, triggered at irregular
intervals via timer interrupt:

    run_timer_softirq -> dccp_keepalive_timer
                      -> inet_csk_reqsk_queue_prune
                      -> reqsk_free
                      -> dccp_v6_reqsk_destructor

The latter function is the problem and is also the last function to be called
in said kernel panic.

In any case, there is a real problem with allocating the right request_sock
which is what this patch tackles.

It fixes the following problem:
 - application listens on PF_INET6
 - DCCPv4 packet comes in, is handed over to dccp_v4_do_rcv, from there
   to dccp_v4_conn_request

Now: socket is PF_INET6, packet is IPv4. The following code then furnishes the
connection with IPv6 - request_sock operations:

   req = reqsk_alloc(sk->sk_prot->rsk_prot);

The first problem is that all further incoming packets will get a Reset since
the connection can not be looked up.

The second problem is worse:
 --> reqsk_alloc is called instead of inet6_reqsk_alloc
 --> consequently inet6_rsk_offset is never set (dangling pointer)
 --> the request_sock_ops are nevertheless still dccp6_request_ops
 --> destructor is called via reqsk_free
 --> dccp_v6_reqsk_destructor tries to free random memory location (inet6_rsk_offset not set)
 --> panic

I have tested this for a while, DCCP sockets are now handled correctly in all
three scenarios (v4/v6 only/v4-mapped).

Commiter note: I've added the dccp_request_sock_ops forward declaration to keep
               the tree building and to reduce the size of the patch for 2.6.19,
               later I'll move the functions to the top of the affected source
               code to match what we have in the TCP counterpart, where this
               problem hasn't existed in the first place, dumb me not to have
               done the same thing on DCCP land 8)
Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
      82709531
  3. 21 Oct, 2006 36 commits