linux.git/drivers/net/ppp_generic.c, branch v2.6.31

ppp: fix lost fragments in ppp_mp_explode() (resubmit)

2009-08-02T19:20:31+00:00

This patch fixes the corner cases where the sum of MTU of the free
channels (adjusted for fragmentation overheads) is less than the MTU
of PPP link.  There are at least 3 situations where this case might
arise:

- some of the channels are busy

- the multilink session is running in a degraded state (i.e. with less
than its full complement of active channels)

- by design, where multilink protocol is being used to artificially
increase the effective link MTU of a single link.

Without this patch, at most 1 fragment is ever sent per free channel
for a given PPP frame and any remaining part of the PPP frame that
does not fit into those fragments is silently discarded.

This patch restores the original behaviour which was broken by commit
9c705260feea6ae329bc6b6d5f6d2ef0227eda0a 'ppp:ppp_mp_explode()
redesign'.  Once all 'free' channels have been given a fragment, an
additional fragment is queued to each available channel in turn, as many
times as necessary, until the entire PPP frame has been consumed.

Signed-off-by: Ben McKeegan 
Signed-off-by: David S. Miller

ppp: unset IFF_XMIT_DST_RELEASE in ppp_setup()

2009-05-19T21:24:37+00:00

Jarek pointed pppoe can call back dev_queue_xmit(), and might need
skb->dst, so its safer to unset IFF_XMIT_DST_RELEASE on ppp devices.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

ppp: ppp_mp_explode() redesign

2009-03-13T23:09:12+00:00

I found the PPP subsystem to not work properly when connecting channels
with different speeds to the same bundle.

Problem Description:

As the "ppp_mp_explode" function fragments the sk_buff buffer evenly
among the PPP channels that are connected to a certain PPP unit to
make up a bundle, if we are transmitting using an upper layer protocol
that requires an Ack before sending the next packet (like TCP/IP for
example), we will have a bandwidth bottleneck on the slowest channel
of the bundle.

Let's clarify by an example. Let's consider a scenario where we have
two PPP links making up a bundle: a slow link (10KB/sec) and a fast
link (1000KB/sec) working at the best (full bandwidth). On the top we
have a TCP/IP stack sending a 1000 Bytes sk_buff buffer down to the
PPP subsystem. The "ppp_mp_explode" function will divide the buffer in
two fragments of 500B each (we are neglecting all the headers, crc,
flags etc?.). Before the TCP/IP stack sends out the next buffer, it
will have to wait for the ACK response from the remote peer, so it
will have to wait for both fragments to have been sent over the two
PPP links, received by the remote peer and reconstructed. The
resulting behaviour is that, rather than having a bundle working
@1010KB/sec (the sum of the channels bandwidths), we'll have a bundle
working @20KB/sec (the double of the slowest channels bandwidth).


Problem Solution:

The problem has been solved by redesigning the "ppp_mp_explode"
function in such a way to make it split the sk_buff buffer according
to the speeds of the underlying PPP channels (the speeds of the serial
interfaces respectively attached to the PPP channels). Referring to
the above example, the redesigned "ppp_mp_explode" function will now
divide the 1000 Bytes buffer into two fragments whose sizes are set
according to the speeds of the channels where they are going to be
sent on (e.g .  10 Byets on 10KB/sec channel and 990 Bytes on
1000KB/sec channel).  The reworked function grants the same
performances of the original one in optimal working conditions (i.e. a
bundle made up of PPP links all working at the same speed), while
greatly improving performances on the bundles made up of channels
working at different speeds.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: David S. Miller

ppp: remove some pointless conditionals before kfree_skb()

2009-02-27T07:07:30+00:00

Remove some pointless conditionals before kfree_skb().

Signed-off-by: Wei Yongjun 
Signed-off-by: David S. Miller

ppp_generic: Simplify tx_dropped stats

2009-02-27T07:02:55+00:00

Local variable dev = ppp->dev

Signed-off-by: Paulius Zaleckas 
Signed-off-by: David S. Miller

drivers/net/ppp*.c: fix sparse warnings: fix signedness

2009-02-18T01:21:12+00:00

Fix this sparse warnings:
  drivers/net/ppp_generic.c:919:43: warning: incorrect type in argument 1 (different signedness)
  drivers/net/pppoe.c:1195:43: warning: incorrect type in argument 1 (different signedness)
  drivers/net/pppol2tp.c:2666:43: warning: incorrect type in argument 1 (different signedness)

Signed-off-by: Hannes Eder 
Acked-by: Cyrill Gorcunov 
Signed-off-by: David S. Miller

ppp: section fixes re netns

2009-02-10T02:05:16+00:00

PPP is modular code so no initdata on netns hooks.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller

net: ppp_generic - introduce net-namespace functionality v2

2009-01-21T23:55:35+00:00

- Each namespace contains ppp channels and units separately
  with appropriate locks

Signed-off-by: Cyrill Gorcunov 
Signed-off-by: David S. Miller

net: ppp_generic - fix regressions caused by IDR conversion

2009-01-13T06:11:56+00:00

The commits:

	7a95d267fb62cd6b80ef73be0592bbbe1dbd5df7
	("net: ppp_generic - use idr technique instead of cardmaps")

	ab5024ab23b78c86a0a1425defcdde48710fe449
	("net: ppp_generic - use DEFINE_IDR for static initialization")

introduced usage of IDR functionality but broke userspace side.

Before this commits it was possible to allocate new ppp interface with
specified number. Now it fails with EINVAL.  Fix it by trying to
allocate interface with specified unit number and return EEXIST if
fail which allow pppd to ask us to allocate new unit number.

And fix messages on memory allocation fails - add details that it's
PPP module who is complaining.

Signed-off-by: Cyrill Gorcunov 
Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2008-12-24T01:56:23+00:00

Conflicts:

	drivers/net/ppp_generic.c