From: Michal Ostrowski <mostrows@speakeasy.net>
To: tip@internetwork-ag.de
Cc: "David S. Miller" <davem@redhat.com>,
linux-kernel@vger.kernel.org, paulus@samba.org,
linux-ppp@vger.kernel.org
Subject: Re: [PATCH] ppp_generic causes skput:under: w/ pppoatm and vc-encaps
Date: 14 Nov 2001 09:23:53 -0500 [thread overview]
Message-ID: <1005747834.8776.5.camel@brick.watson.ibm.com> (raw)
In-Reply-To: <20011113.210221.55509229.davem@redhat.com>
In-Reply-To: <3BF190F0.3FB26BD0@internetwork-ag.de> <20011113.210221.55509229.davem@redhat.com>
If you set the hdrlen field of the ppp_channel that pppoatm registers
(pvcc->chan.hdrlen, in pppoatm_assign_vcc()) then ppp_generic will
always over-allocate skb space to allow for extra headers to be pushed
in. This mechanism was put is so that we wouldn't have to copy the
frame in order to slap on PPPoE headers onto it. I think it's a good
idea to be doing this, especially if you're going to play with
hard_header_len.
If you look at pppoatm_send(), you'll see that you do an
skb_realloc_headroom if there's no space for the headers. If
pvcc->chan.hdrlen is set properly then this will be the exceptional,
rather than the common case.
> Here is my "better fix". In pppoatm, we should be increasing the
> device header length appropriately. ie. dev->hard_header_len needs to
> be increased in the pppoatm driver when vc-encaps is used.
>
> Franks a lot,
> David S. Miller
> davem@redhat.com
--
Michal Ostrowski
mostrows@speakeasy.net
next prev parent reply other threads:[~2001-11-14 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-13 21:30 [PATCH] ppp_generic causes skput:under: w/ pppoatm and vc-encaps Till Immanuel Patzschke
2001-11-14 5:02 ` David S. Miller
2001-11-14 11:13 ` [PATCH] ppp_generic causes skput:under: w/ pppoatm andvc-encaps Till Immanuel Patzschke
2001-11-14 11:48 ` David S. Miller
2001-11-14 14:23 ` Michal Ostrowski [this message]
2001-11-14 14:28 ` [PATCH] ppp_generic causes skput:under: w/ pppoatm and vc-encaps David S. Miller
2001-11-14 14:41 ` Till Immanuel Patzschke
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=1005747834.8776.5.camel@brick.watson.ibm.com \
--to=mostrows@speakeasy.net \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=paulus@samba.org \
--cc=tip@internetwork-ag.de \
/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