Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 05 6月, 2008 4 次提交
    • D
      Merge branch 'davem-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 · 8b91ac09
      由 David S. Miller 提交于
      8b91ac09
    • 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
  3. 04 6月, 2008 10 次提交
  5. 03 6月, 2008 6 次提交
  7. 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
  9. 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
  11. 31 5月, 2008 18 次提交