[Top] [All Lists]

Re: [DEBUG]: sk_forward_alloc assertion failures

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [DEBUG]: sk_forward_alloc assertion failures
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 15 Jan 2005 16:45:47 +1100
Cc: anton@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050114205543.5acb0d68.davem@xxxxxxxxxxxxx>
References: <20050114120322.GA28449@xxxxxxxxxxxxxxxxxxx> <20050114110352.23c94ab9.davem@xxxxxxxxxxxxx> <20050114203452.GA1277@xxxxxxxxxxxxxxxxxxx> <20050114132757.4ca3153a.davem@xxxxxxxxxxxxx> <20050114213829.GA12454@xxxxxxxxxxxxxxxxxxx> <20050114133611.69ff0bb2.davem@xxxxxxxxxxxxx> <20050114215504.GA12569@xxxxxxxxxxxxxxxxxxx> <20050114140426.5cf06f0c.davem@xxxxxxxxxxxxx> <20050114224745.GA13180@xxxxxxxxxxxxxxxxxxx> <20050114205543.5acb0d68.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Fri, Jan 14, 2005 at 08:55:43PM -0800, David S. Miller wrote:
> Doing the adjustments at tcp_write_xmit() time also runs into the
> problem you mentioned where we're just blindly subtracting from
> sk_forward_alloc.

Not really because what we're doing there is increasing sk_forward_alloc,
just as we do in tcp_trim_head.

Anyway, I'm not terribly attached to that idea since we're doing
a page's worth of data each time around the loop anyway so it's
not too bad.
> Here's a patch against current BK that tries to do that.  See any
> holes? :-)

Just one little problem :)

> +             if (sk->sk_forward_alloc < copy &&
> +                 !sk_stream_mem_schedule(sk, copy, 0))

You want to have sk->sk_allocation here instead of 0.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

<Prev in Thread] Current Thread [Next in Thread>