All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH][RFC] network splice receive
Date: Tue, 12 Jun 2007 14:40:05 +0200	[thread overview]
Message-ID: <20070612124005.GC18832@kernel.dk> (raw)
In-Reply-To: <20070612123540.GB16477@2ka.mipt.ru>

On Tue, Jun 12 2007, Evgeniy Polyakov wrote:
> > > > > and putting cloned skb into private field instead of 
> > > > > original on in spd_fill_page() ends up without kernel hung.
> > > > 
> > > > Why? Seems pointless to allocate a clone just to hold on to the skb, a
> > > > reference should be equally good. I would not be opposed to doing it
> > > > this way, I just don't see what a clone buys us as compared to just
> > > > holding that reference to the skb.
> > > 
> > > Receiving code does not expect shared skbs - too many fields are changed
> > > with assumptions that it is a private copy.
> > 
> > Actually the main problem is that tcp_read_sock() unconditionally frees
> > the skb, so it wouldn't help if we grabbed a reference to it. I've yet
> > to receive an explanation of why it does so, seem awkward and violates
> > the whole principle of reference counted objects. Davem??
> > 
> > So for now, skb_splice_bits() clones the incoming skb to avoid that. I'd
> > hope we can get rid of that by fixing tcp_read_sock(), though.
> 
> It does that because it knows, that skb is not allowed to be shared
> there. Similar things are being done in udp for example - code changes
> internal mebers of skb, since it knows skb is not shared.
> 
> For example generic_make_request() is not allowed to change, say, 
> bio->bi_sector or bi_destructor, since it does not own a block request, 
> not matter what bi_cnt is. From another side, ->bi_destructor() can do
> whatever it wants with bio without any check for its reference counter.

But generic_make_request() DOES change ->bi_sector, that's how partition
remapping works :-). The destructor can of course do whatever it wants,
by definition the bio is not referenced at that point (or it would not
have been called). So while I think your analogy is quite poor, I do now
follow the code (even if I think it's ugly). There's quite a big
difference between changing parts of the elements of a structure to just
grabbing a reference to it. If the skb cannot be referenced, skb_get()
should return NULL.

But that aside, I see the issue. I'll just stick to the clone, it works
fine as-is (well almost, there's a leak there, but functionally it's
ok!).

-- 
Jens Axboe


  reply	other threads:[~2007-06-12 12:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-05  8:05 [PATCH][RFC] network splice receive Jens Axboe
2007-06-05 11:45 ` Jens Axboe
2007-06-05 12:20   ` Jens Axboe
2007-06-05 12:34     ` jamal
2007-06-06  7:14       ` Jens Axboe
2007-06-05 13:34 ` Evgeniy Polyakov
2007-06-05 14:31 ` Evgeniy Polyakov
2007-06-05 14:49   ` Evgeniy Polyakov
2007-06-06  7:17   ` Jens Axboe
2007-06-07  8:09     ` Evgeniy Polyakov
2007-06-07 10:51       ` Jens Axboe
2007-06-07 14:58         ` Evgeniy Polyakov
2007-06-08  7:48           ` Jens Axboe
2007-06-08  8:06             ` David Miller
2007-06-08  8:38               ` Jens Axboe
2007-06-08  8:56                 ` Evgeniy Polyakov
2007-06-08  9:04                   ` Jens Axboe
2007-06-08 13:58                     ` Evgeniy Polyakov
2007-06-08 14:14                       ` Jens Axboe
2007-06-08 14:57                         ` Evgeniy Polyakov
2007-06-08 15:19                           ` Jens Axboe
2007-06-08 15:30                           ` Evgeniy Polyakov
2007-06-09  6:36                             ` Jens Axboe
2007-06-12 11:29                               ` Evgeniy Polyakov
2007-06-12 11:33                                 ` Jens Axboe
2007-06-12 12:35                                   ` Evgeniy Polyakov
2007-06-12 12:40                                     ` Jens Axboe [this message]
2007-06-12 13:11                                       ` Evgeniy Polyakov
2007-06-12 13:11                                         ` Jens Axboe
2007-06-11  8:00                             ` Jens Axboe

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=20070612124005.GC18832@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=davem@davemloft.net \
    --cc=johnpol@2ka.mipt.ru \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.