Skip to content

L
linux
Switch branch/tag
  1. 03 Mar, 2007 10 commits
  3. 24 Feb, 2007 21 commits
  5. 20 Feb, 2007 2 commits
  7. 05 Feb, 2007 7 commits
    • Chris Wright's avatar
      Linux 2.6.19.3 · b321cb58
      Chris Wright authored
      b321cb58
    • Ingo Molnar's avatar
      [PATCH] sched: fix cond_resched_softirq() offset · 9868646d
      Ingo Molnar authored 
      Remove the __resched_legal() check: it is conceptually broken.  The biggest
problem it had is that it can mask buggy cond_resched() calls.  A
cond_resched() call is only legal if we are not in an atomic context, with
two narrow exceptions:

 - if the system is booting
 - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set

But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).

Furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq().  (which is
only called from softirq-off sections, hence the code did nothing.)

The fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
[chrisw: backport to 2.6.19.2]
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      9868646d
    • Kirill Korotaev's avatar
      [PATCH] move_task_off_dead_cpu() should be called with disabled ints · 56cf7709
      Kirill Korotaev authored 
      move_task_off_dead_cpu() requires interrupts to be disabled, while
migrate_dead() calls it with enabled interrupts.  Added appropriate
comments to functions and added BUG_ON(!irqs_disabled()) into
double_rq_lock() and double_lock_balance() which are the origin sources of
such bugs.
Signed-off-by: default avatarKirill Korotaev <dev@openvz.org>
Acked-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      56cf7709
    • Trond Myklebust's avatar
      [PATCH] SUNRPC: Give cloned RPC clients their own rpc_pipefs directory · 16a2980e
      Trond Myklebust authored 
      This patch fixes a regression in 2.6.19 in which the use of multiple
krb5 mounts against the same NFS server may result in an Oops on
unmount. The Oops is due to the fact that multiple NFS krb5 clients may
end up inadvertently sharing the same rpc_pipefs upcall pipe. The first
client to 'umount' will unlink that shared pipe, causing an Oops.

The solution is to give each client their own upcall pipe. This fix has
been in mainline since 2.6.20-rc1.
Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
[chrisw: backport to 2.6.19.2]
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      16a2980e
    • Patrick McHardy's avatar
      [PATCH] NETFILTER: xt_connbytes: fix division by zero · 81a86f15
      Patrick McHardy authored 
      When the packet counter of a connection is zero a division by zero
occurs in div64_64(). Fix that by using zero as average value, which
is correct as long as the packet counter didn't overflow, at which
point we have lost anyway.

Additionally we're probably going to go back to 64 bit counters
in 2.6.21.

Based on patch from Jonas Berlin <xkr47@outerspace.dyndns.org>,
with suggestions from KOVACS Krisztian <hidden@balabit.hu>.
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      81a86f15
    • Masayuki Nakagawa's avatar
      [PATCH] TCP: skb is unexpectedly freed. · 6e3e53bb
      Masayuki Nakagawa authored 
      I encountered a kernel panic with my test program, which is a very
simple IPv6 client-server program.

The server side sets IPV6_RECVPKTINFO on a listening socket, and the
client side just sends a message to the server.  Then the kernel panic
occurs on the server.  (If you need the test program, please let me
know. I can provide it.)

This problem happens because a skb is forcibly freed in
tcp_rcv_state_process().

When a socket in listening state(TCP_LISTEN) receives a syn packet,
then tcp_v6_conn_request() will be called from
tcp_rcv_state_process().  If the tcp_v6_conn_request() successfully
returns, the skb would be discarded by __kfree_skb().

However, in case of a listening socket which was already set
IPV6_RECVPKTINFO, an address of the skb will be stored in
treq->pktopts and a ref count of the skb will be incremented in
tcp_v6_conn_request().  But, even if the skb is still in use, the skb
will be freed.  Then someone still using the freed skb will cause the
kernel panic.

I suggest to use kfree_skb() instead of __kfree_skb().
Signed-off-by: default avatarMasayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      6e3e53bb
    • Baruch Even's avatar
      [PATCH] TCP: Fix sorting of SACK blocks. · 39460cfb
      Baruch Even authored 
      The sorting of SACK blocks actually munges them rather than sort,
causing the TCP stack to ignore some SACK information and breaking the
assumption of ordered SACK blocks after sorting.

The sort takes the data from a second buffer which isn't moved causing
subsequent data moves to occur from the wrong location. The fix is to
use a temporary buffer as a normal sort does.
Signed-off-By: default avatarBaruch Even <baruch@ev-en.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      39460cfb
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7