On 14/10/05, Herbert Xu <[EMAIL PROTECTED]> wrote:
> David S. Miller <[EMAIL PROTECTED]> wrote:
> >
> > One thing you can probably do for this bug is to mark data packets
> > explicitly somehow, perhaps in the SKB control block DCCP already
> > uses for other data. Put some boolean in there, set it true for
> > data packets. Then change the test in dccp_transmit_skb() as
> > appropriate to test the boolean flag instead of "skb_cloned(skb)".
>
> I agree. In fact we already have that flag, it's called skb->sk.
> So here is patch to test that instead of skb_cloned().
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> diff --git a/net/dccp/output.c b/net/dccp/output.c
> --- a/net/dccp/output.c
> +++ b/net/dccp/output.c
> @@ -62,10 +62,8 @@ int dccp_transmit_skb(struct sock *sk, s
>
> skb->h.raw = skb_push(skb, dccp_header_size);
> dh = dccp_hdr(skb);
> - /*
> - * Data packets are not cloned as they are never retransmitted
> - */
> - if (skb_cloned(skb))
> +
> + if (!skb->sk)
> skb_set_owner_w(skb, sk);
>
> /* Build DCCP header and checksum it. */
>
Acked-by: Ian McDonald <[EMAIL PROTECTED]>
This fixes the immediate problem but it just raises another one
straight away which I've produced below. This happens most of the time
(but not all of the time) when running ttcp to non-existent computer.
I think we should put in Herbert's patch for the following reasons:
- it seems correct
- it is similar to what I was thinking
- it makes the current oops go away
I think the new oops is due to either stack corruption or else a
non-existent callback. Comments?
Unable to handle kernel paging request at virtual address 5a5a5ade
printing eip:
c033a890
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: dccp_ccid3 dccp_tfrc_lib dccp e100 3c59x
CPU: 0
EIP: 0060:[<c033a890>] Not tainted VLI
EFLAGS: 00010246 (2.6.14-rc3)
EIP is at icmp_send+0x130/0x3d0
eax: 5a5a5a5a ebx: c6ee3360 ecx: 5a5a5a5a edx: 0000005a
esi: 00000000 edi: c043de58 ebp: c043dea0 esp: c043dd64
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c043c000 task=c03bcba0)
Stack: c043de58 c7319120 c043dd94 c031b22f c0319b7c 00000000 c7415548 c043ddb4
00000000 c70a8034 c6ee356c 00000000 c043de64 c031b6e5 c7319b7c c03766fb
00000000 00000000 00000000 00000000 c7415548 c01d18ed 0000005b c03573a0
Call Trace:
[<c01034af>] show_stack+0x7f/0xa0
[<c0103658>] show_registers+0x158/0x1c0
[<c0103838>] die+0xc8/0x140
[<c034f81e>] do_page_fault+0x2de/0x60e
[<c0103173>] error_code+0x4f/0x54
[<5a5a5a5a>] 0x5a5a5a5a
Ian
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
