1. 05 6月, 2008 4 次提交
    • D
    • I
      tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp)) · 8aca6cb1
      Ilpo Järvinen 提交于
      It is possible that this skip path causes TCP to end up into an
      invalid state where ca_state was left to CA_Open while some
      segments already came into sacked_out. If next valid ACK doesn't
      contain new SACK information TCP fails to enter into
      tcp_fastretrans_alert(). Thus at least high_seq is set
      incorrectly to a too high seqno because some new data segments
      could be sent in between (and also, limited transmit is not
      being correctly invoked there). Reordering in both directions
      can easily cause this situation to occur.
      
      I guess we would want to use tcp_moderate_cwnd(tp) there as well
      as it may be possible to use this to trigger oversized burst to
      network by sending an old ACK with huge amount of SACK info, but
      I'm a bit unsure about its effects (mainly to FlightSize), so to
      be on the safe side I just currently fixed it minimally to keep
      TCP's state consistent (obviously, such nasty ACKs have been
      possible this far). Though it seems that FlightSize is already
      underestimated by some amount, so probably on the long term we
      might want to trigger recovery there too, if appropriate, to make
      FlightSize calculation to resemble reality at the time when the
      losses where discovered (but such change scares me too much now
      and requires some more thinking anyway how to do that as it
      likely involves some code shuffling).
      
      This bug was found by Brian Vowell while running my TCP debug
      patch to find cause of another TCP issue (fackets_out
      miscount).
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8aca6cb1
    • 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
    • D
      netfilter: xt_connlimit: fix accouning when receive RST packet in ESTABLISHED state · d2ee3f2c
      Dong Wei 提交于
      In xt_connlimit match module, the counter of an IP is decreased when
      the TCP packet is go through the chain with ip_conntrack state TW.
      Well, it's very natural that the server and client close the socket
      with FIN packet. But when the client/server close the socket with RST
      packet(using so_linger), the counter for this connection still exsit.
      The following patch can fix it which is based on linux-2.6.25.4
      Signed-off-by: NDong Wei <dwei.zh@gmail.com>
      Acked-by: NJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2ee3f2c
  2. 04 6月, 2008 10 次提交
  3. 03 6月, 2008 6 次提交
  4. 02 6月, 2008 1 次提交
    • A
      [CRYPTO] cts: Init SG tables · c4913c7b
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	modprobe tcrypt		# with CONFIG_DEBUG_SG=y
      
      testing cts(cbc(aes)) encryption
      test 1 (128 bit key):
      ------------[ cut here ]------------
      kernel BUG at include/linux/scatterlist.h:65!
      invalid opcode: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0 
      Modules linked in: tea xts twofish twofish_common tcrypt(+) [maaaany]
      Pid: 16151, comm: modprobe Not tainted 2.6.26-rc4-fat #7
      RIP: 0010:[<ffffffffa0bf032e>]  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
      RSP: 0018:ffff81016f497a88  EFLAGS: 00010286
      RAX: ffffe20009535d58 RBX: ffff81016f497af0 RCX: 0000000087654321
      RDX: ffff8100010d4f28 RSI: ffff81016f497ee8 RDI: ffff81016f497ac0
      RBP: ffff81016f497c38 R08: 0000000000000000 R09: 0000000000000011
      R10: ffffffff00000008 R11: ffff8100010d4f28 R12: ffff81016f497ac0
      R13: ffff81016f497b30 R14: 0000000000000010 R15: 0000000000000010
      FS:  00007fac6fa276f0(0000) GS:ffffffff8060e000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f12ca7cc000 CR3: 000000016f441000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
      Process modprobe (pid: 16151, threadinfo ffff81016f496000, task ffff8101755b4ae0)
      Stack:  0000000000000001 ffff81016f496000 ffffffff80719f78 0000000000000001
       0000000000000001 ffffffff8020c87c ffff81016f99c918 20646c756f772049
       65687420656b696c 0000000000000020 0000000000000000 0000000033341102
      Call Trace:
       [<ffffffff8020c87c>] ? restore_args+0x0/0x30
       [<ffffffffa04aa311>] ? :aes_generic:crypto_aes_expand_key+0x311/0x369
       [<ffffffff802ab453>] ? check_object+0x15a/0x213
       [<ffffffff802aad22>] ? init_object+0x6e/0x76
       [<ffffffff802ac3ae>] ? __slab_free+0xfc/0x371
       [<ffffffffa0bf05ed>] :cts:crypto_cts_encrypt+0xbb/0xca
       [<ffffffffa07108de>] ? :crypto_blkcipher:setkey+0xc7/0xec
       [<ffffffffa07110b8>] :crypto_blkcipher:async_encrypt+0x38/0x3a
       [<ffffffffa2ce9341>] :tcrypt:test_cipher+0x261/0x7c6
       [<ffffffffa2cfd9df>] :tcrypt:tcrypt_mod_init+0x9df/0x1b30
       [<ffffffff80261e35>] sys_init_module+0x9e/0x1b2
       [<ffffffff8020c15a>] system_call_after_swapgs+0x8a/0x8f
      Code: 45 c0 e8 aa 24 63 df 48 c1 e8 0c 48 b9 00 00 00 00 00 e2 ff ff 48 8b 55 88 48 6b c0 68 48 01 c8 b9 21 43 65 87 48 39 4d 80 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 4c 89 ef 44 89 
      RIP  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
       RSP <ffff81016f497a88>
      ---[ end trace e8bahiarjand37fd ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c4913c7b
  5. 01 6月, 2008 1 次提交
    • S
      kbuild: fix $(src) assignmnet with external modules · 96d97f26
      Sam Ravnborg 提交于
      When we introduced support for KBUILD_EXTRA_SYMBOLS
      we started to include the externam module's kbuild
      file when doing the final modpost step.
      
      As external modules often do:
      ccflags-y := -I$(src)
      
      We had problems because $(src) was unassinged and
      gcc then used the next parameter for -I resulting in
      strange build failures.
      
      Fix is to assign $(src) and $(obj) when building
      external modules.
      
      This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10798Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Tvrtko <tvrtko.ursulin@sophos.com>
      Cc: Andrea Arcangeli <andrea@qumranet.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      96d97f26
  6. 31 5月, 2008 18 次提交