From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: race in skb_splice_bits?
Date: Wed, 28 May 2008 12:52:41 +0400 [thread overview]
Message-ID: <20080528085241.GA30367@2ka.mipt.ru> (raw)
In-Reply-To: <200805280259.30931.opurdila@ixiacom.com>
On Wed, May 28, 2008 at 02:59:30AM +0300, Octavian Purdila (opurdila@ixiacom.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
next prev parent reply other threads:[~2008-05-28 8:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-27 0:25 race in skb_splice_bits? Octavian Purdila
2008-05-27 2:08 ` Ben Hutchings
2008-05-27 10:41 ` Octavian Purdila
2008-05-27 11:01 ` Evgeniy Polyakov
2008-05-27 11:08 ` Ben Hutchings
2008-05-27 11:52 ` Evgeniy Polyakov
2008-05-27 11:56 ` Evgeniy Polyakov
2008-05-27 12:53 ` Octavian Purdila
2008-05-27 13:21 ` Evgeniy Polyakov
2008-05-27 14:03 ` Evgeniy Polyakov
2008-05-27 14:39 ` Octavian Purdila
2008-05-27 15:09 ` Evgeniy Polyakov
2008-05-27 15:12 ` Evgeniy Polyakov
2008-05-27 15:22 ` Evgeniy Polyakov
2008-05-27 15:33 ` Octavian Purdila
2008-05-27 15:47 ` Evgeniy Polyakov
2008-05-27 17:28 ` Evgeniy Polyakov
2008-05-27 23:59 ` Octavian Purdila
2008-05-28 8:52 ` Evgeniy Polyakov [this message]
2008-05-28 13:20 ` Octavian Purdila
2008-05-28 14:11 ` Evgeniy Polyakov
2008-05-28 15:20 ` Octavian Purdila
2008-05-28 15:42 ` Evgeniy Polyakov
2008-05-28 17:08 ` Octavian Purdila
2008-05-28 17:51 ` Evgeniy Polyakov
2008-05-28 18:02 ` Octavian Purdila
2008-05-28 20:01 ` Jarek Poplawski
2008-05-28 20:09 ` Octavian Purdila
2008-05-28 20:16 ` Jarek Poplawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080528085241.GA30367@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).