1. 08 10月, 2008 23 次提交
  2. 01 10月, 2008 1 次提交
    • I
      ipv6: almost identical frag hashing funcs combined · 93c8b90f
      Ilpo Järvinen 提交于
      $ diff-funcs ip6qhashfn reassembly.c netfilter/nf_conntrack_reasm.c
       --- reassembly.c:ip6qhashfn()
       +++ netfilter/nf_conntrack_reasm.c:ip6qhashfn()
      @@ -1,5 +1,5 @@
      -static unsigned int ip6qhashfn(__be32 id, struct in6_addr *saddr,
      -			       struct in6_addr *daddr)
      +static unsigned int ip6qhashfn(__be32 id, const struct in6_addr *saddr,
      +			       const struct in6_addr *daddr)
       {
       	u32 a, b, c;
      
      @@ -9,7 +9,7 @@
      
       	a += JHASH_GOLDEN_RATIO;
       	b += JHASH_GOLDEN_RATIO;
      -	c += ip6_frags.rnd;
      +	c += nf_frags.rnd;
       	__jhash_mix(a, b, c);
      
       	a += (__force u32)saddr->s6_addr32[3];
      
      And codiff xx.o.old xx.o.new:
      
      net/ipv6/netfilter/nf_conntrack_reasm.c:
        ip6qhashfn         | -512
        nf_hashfn          |   +6
        nf_ct_frag6_gather |  +36
       3 functions changed, 42 bytes added, 512 bytes removed, diff: -470
      net/ipv6/reassembly.c:
        ip6qhashfn    | -512
        ip6_hashfn    |   +7
        ipv6_frag_rcv |  +89
       3 functions changed, 96 bytes added, 512 bytes removed, diff: -416
      
      net/ipv6/reassembly.c:
        inet6_hash_frag | +510
       1 function changed, 510 bytes added, diff: +510
      
      Total: -376
      
      Compile tested.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93c8b90f
  3. 25 9月, 2008 1 次提交
  4. 27 7月, 2008 1 次提交
  5. 26 7月, 2008 1 次提交
  6. 24 7月, 2008 1 次提交
  7. 20 7月, 2008 1 次提交
  8. 08 7月, 2008 2 次提交
  9. 28 6月, 2008 1 次提交
  10. 25 6月, 2008 1 次提交
  11. 10 6月, 2008 4 次提交
  12. 05 6月, 2008 1 次提交
    • J
      netfilter: nf_conntrack_ipv6: fix inconsistent lock state in nf_ct_frag6_gather() · b9c69896
      Jarek Poplawski 提交于
      [   63.531438] =================================
      [   63.531520] [ INFO: inconsistent lock state ]
      [   63.531520] 2.6.26-rc4 #7
      [   63.531520] ---------------------------------
      [   63.531520] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
      [   63.531520] tcpsic6/3864 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   63.531520]  (&q->lock#2){-+..}, at: [<c07175b0>] ipv6_frag_rcv+0xd0/0xbd0
      [   63.531520] {softirq-on-W} state was registered at:
      [   63.531520]   [<c0143bba>] __lock_acquire+0x3aa/0x1080
      [   63.531520]   [<c0144906>] lock_acquire+0x76/0xa0
      [   63.531520]   [<c07a8f0b>] _spin_lock+0x2b/0x40
      [   63.531520]   [<c0727636>] nf_ct_frag6_gather+0x3f6/0x910
       ...
      
      According to this and another similar lockdep report inet_fragment
      locks are taken from nf_ct_frag6_gather() with softirqs enabled, but
      these locks are mainly used in softirq context, so disabling BHs is
      necessary.
      Reported-and-tested-by: NEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9c69896
  13. 29 4月, 2008 1 次提交
    • A
      netfilter: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets · 9a732ed6
      Arnaud Ebalard 提交于
      While reinjecting *bigger* modified versions of IPv6 packets using
      libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
      but I get the following on recents kernels (2.6.25, trace below is
      against today's net-2.6 git tree):
      
      skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
      ------------[ cut here ]------------
      invalid opcode: 0000 [#1] PREEMPT 
      Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
      Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80 
             f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60 
             c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c 
      Call Trace:
       [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
       [<c04cdbfc>] ? skb_put+0x3c/0x40
       [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
       [<c04fd115>] ? nfnetlink_rcv_msg+0xf5/0x160
       [<c04fd03e>] ? nfnetlink_rcv_msg+0x1e/0x160
       [<c04fd020>] ? nfnetlink_rcv_msg+0x0/0x160
       [<c04f8ed7>] ? netlink_rcv_skb+0x77/0xa0
       [<c04fcefc>] ? nfnetlink_rcv+0x1c/0x30
       [<c04f8c73>] ? netlink_unicast+0x243/0x2b0
       [<c04cfaba>] ? memcpy_fromiovec+0x4a/0x70
       [<c04f9406>] ? netlink_sendmsg+0x1c6/0x270
       [<c04c8244>] ? sock_sendmsg+0xc4/0xf0
       [<c011970d>] ? set_next_entity+0x1d/0x50
       [<c0133a80>] ? autoremove_wake_function+0x0/0x40
       [<c0118f9e>] ? __wake_up_common+0x3e/0x70
       [<c0342fbf>] ? n_tty_receive_buf+0x34f/0x1280
       [<c011d308>] ? __wake_up+0x68/0x70
       [<c02cea47>] ? copy_from_user+0x37/0x70
       [<c04cfd7c>] ? verify_iovec+0x2c/0x90
       [<c04c837a>] ? sys_sendmsg+0x10a/0x230
       [<c011967a>] ? __dequeue_entity+0x2a/0xa0
       [<c011970d>] ? set_next_entity+0x1d/0x50
       [<c0345397>] ? pty_write+0x47/0x60
       [<c033d59b>] ? tty_default_put_char+0x1b/0x20
       [<c011d2e9>] ? __wake_up+0x49/0x70
       [<c033df99>] ? tty_ldisc_deref+0x39/0x90
       [<c033ff20>] ? tty_write+0x1a0/0x1b0
       [<c04c93af>] ? sys_socketcall+0x7f/0x260
       [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
       [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
       =======================
      Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0 
      EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8
      
      
      Looking at the code, I ended up in nfq_mangle() function (called by
      nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
      the increased size of data passed to the function. AFAICT, it should ask
      for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
      resulting sk_buff has not enough space to support the skb_put(skb, diff)
      call a few lines later, this results in the call to skb_over_panic().
      
      The patch below asks for allocation of a copy with enough space for
      mangled packet and the same amount of headroom as old sk_buff. While
      looking at how the regression appeared (e2b58a67), I noticed the same
      pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
      those locations too.
      
      Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
      are ok (2.6.25 and today's net-2.6 git tree).
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a732ed6
  14. 14 4月, 2008 1 次提交