public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
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 18:11:04 +0400	[thread overview]
Message-ID: <20080528141104.GA5543@2ka.mipt.ru> (raw)
In-Reply-To: <200805281620.55578.opurdila@ixiacom.com>

On Wed, May 28, 2008 at 04:20:55PM +0300, Octavian Purdila (opurdila@ixiacom•com) wrote:
> > 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 
> 
> If the skb was partially consumed then tcp_recv_skb(seq-1) will return the 
> same skb and the offset +1 != skb->len, thus we will not free it.

I understand now, please correct me if I got your idea wrong.
We only ned to search for the skb again only in case we processed it and
it was possible that socket lock was dropped. So, the only needed place
to put tcp_recv_skb() is where you pointed. Next, to find current skb we
have to get sequence number inside its data, and seq-1 is indeed that
case, even if skb was changed under us (like combined with others), we
still will find it in the queue. Offset in tcp_recv_skb() is set to
number of bytes between starting sequence number for skb and given
sequence number, thus if we search for (seq-1), it will point to the
last byte processed by the code, and thus offset will 'point' to last
processed byte, not byte to start from, so we check against (offset+1)
and if (offset+1) equals to the size of the skb found we can free this
skb (in the code below). If it is not the case and skb contains data
behind (offset+1) we break and the rest of the data will be processed
in the next run. If there is no skb, we just break out of the loop.

So yes, your patch is simpler and faster than mine so you should push it
upstream. Fortunately David Miller is in copy and will (David, will
you?) pick it up and push, likely it is also needed for stable?

> Anyways, I am a newbie in this area, so if my logic doesn't make any sense 
> please be patient with me :)

We all are newbies somewhere and even splice code itself is rather new :)


-- 
	Evgeniy Polyakov

  reply	other threads:[~2008-05-28 14:11 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
2008-05-28 13:20                                 ` Octavian Purdila
2008-05-28 14:11                                   ` Evgeniy Polyakov [this message]
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=20080528141104.GA5543@2ka.mipt.ru \
    --to=johnpol@2ka$(echo .)mipt.ru \
    --cc=bhutchings@solarflare$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=opurdila@ixiacom$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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