On 10/14/05, Ian McDonald <[EMAIL PROTECTED]> wrote: > 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
Thanks for testing, I'm still busy with work related stuff :-\ > 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 Seems use after free, lemme give a quick look... - Arnaldo - 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
