Thank you. I was thinking about something like that when I said "not find explicit checks", but I was confused because the sk_buff code is plenty of explicit checks and I understood those checks as a try to make the code self-protected against wrong uses: "I, sk_buff, offer you this interface. Don´t worry too much about my internals: I will complain on your mistakes"
The fact the name of the functionality is generic "fast_clone" and not specific "tcp_fast_clone" drove me to think: "Ok, the allocation of fast-clonable skbs is NOW only in ONE place inside TCP code and sure that they have the implicit checks to avoid this race when they call skb_clone, but -NOW- and -ONE- are not a big guarantee..." A newbie's thought. :) 2007/10/11, Herbert Xu <[EMAIL PROTECTED]>: > Santiago Font Arquer <[EMAIL PROTECTED]> wrote: > > > > If an skb with fast clone available (first "if" true) has > > references in different CPUs (skb->users>1) (I do not find explicit > > checks for this to be impossible), if skb_clone is called > > simultaneously over that skb, both callers can get the same clone (the > > "fast" clone) and different problems follow: wrong "clone_skb->users" > > (1 as expected by the caller, but it should be, to be true, 2), > > fclone_ref set to 3 involving further problems, ... > > Fast clones are only used by TCP where the original skb is > never given to the outside world. This plus the fact that > a given TCP socket is single-threaded makes it safe. > > 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 > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
