lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 28 May 2008 12:52:41 +0400 From: Evgeniy Polyakov <johnpol@....mipt.ru> To: Octavian Purdila <opurdila@...acom.com> Cc: Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org, davem@...emloft.net Subject: Re: race in skb_splice_bits? On Wed, May 28, 2008 at 02:59:30AM +0300, Octavian Purdila (opurdila@...acom.com) wrote: > One doubt though: suppose that while we drop the lock the skb gets aggregated > with the one after it. If the original skb is fully consumed in the receive > actor, then the we will eat the new, aggregated skb, loosing data. How can it be aggregated with another skb? It is only possible that some other reader consumes the data, but in that case sequence number will not match and we will not find skb. > Here is a patch, based on your idea, which tries to cope with the above > scenario. The !skb check was added for the case in which the actor does not > consume anything in the current interration. If it does not get any data, then skb will likely exists and will be consumed in the next run. I preserved old semantic, when we free skb only if we read it whole or in case of fin. With your changes we can also free skb, if it was partially consumed and do not free it at all if skb was not processed becuase it is too old (i.e. it lives in receive queue, but we already read data siwth sequnce number, which corresponds to it), no? -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists