All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Ostrowski <mostrows@us.ibm.com>
To: kuznet@ms2.inr.ac.ru
Cc: davem@redhat.com, linux-kernel@vger.kernel.org,
	linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
Date: 19 Jul 2001 14:00:54 -0400	[thread overview]
Message-ID: <sb666cohk89.fsf@slug.watson.ibm.com> (raw)
In-Reply-To: <200107191727.VAA30738@ms2.inr.ac.ru>
In-Reply-To: <200107191727.VAA30738@ms2.inr.ac.ru>

kuznet@ms2.inr.ac.ru writes:

> Hello!
> 
> SOme short comment on the patch:
> 
> 
> > -	dev_queue_xmit(skb);
> > +	/* The skb we are to transmit may be a copy (see above).  If
> > +	 * this fails, then the caller is responsible for the original
> > +	 * skb, otherwise we must free it.  Also if this fails we must
> > +	 * free the copy that we made.
> > +	 */
> > +
> > +	if (dev_queue_xmit(skb)<0) {
> 
> dev_queue_xmit _frees_ frame, not depending on return value.
> Return value is not a criterium to assume anything.
> 

My mistake.  It seemed perfectly reasonable at 6:00 am.  :-)

However, could we not have dev_queue_xmit behave as such (not free
frame on failure)?  That is, could we extend dev_queue_xmit to tell it
(optionally) that we want the skb back in case of failure?
dev_queue_xmit unconditionally frees the skb in any failure mode,
which is I would venture to say that we could do this.

The reason why I'm proposing this is that ppp_generic.c assumes that
the skb is still available after a transmission failure via pppoe.  To
support the semantics of dev_queue_xmit and ppp_generic we would have
to always copy skb's inside pppoe_xmit.  Then, if dev_queue_xmit fails
the original is deleted.

In the common case dev_queue_xmit will not fail, and so in that case
I'd like to have to avoid making a copy of the skb.

Michal Ostrowski
mostrows@speakeasy.net


  reply	other threads:[~2001-07-19 18:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-17  2:35 kernel panic problem. (smp, iptables?) Andrew Friedley
2001-07-18  3:58 ` [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)) David S. Miller
2001-07-18 14:23   ` Michal Ostrowski
2001-07-19 12:30   ` Michal Ostrowski
2001-07-19 17:27     ` kuznet
2001-07-19 18:00       ` Michal Ostrowski [this message]
2001-07-19 18:17         ` kuznet
2001-07-19 18:57   ` Michal Ostrowski
2001-07-19 23:13     ` David S. Miller
2001-07-19 23:53       ` Andrew Friedley
2001-07-20  7:13   ` Rainer Clasen
2001-07-20  7:28     ` David S. Miller
2001-07-20 15:36       ` Rainer Clasen
2001-07-09 11:51         ` [OOPS] network related crash with Linux 2.4 Moritz Schulte
2001-07-10  5:19           ` Rainer Clasen
2001-08-01 20:21             ` Rainer Clasen
2001-07-22  2:07 ` kernel panic problem. (smp, iptables?) Rusty Russell

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=sb666cohk89.fsf@slug.watson.ibm.com \
    --to=mostrows@us.ibm.com \
    --cc=davem@redhat.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=mostrows@speakeasy.net \
    --cc=netdev@oss.sgi.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 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.