Skip to content

L
linux-davinci
Switch branch/tag
  1. 16 Mar, 2009 6 commits
  3. 14 Mar, 2009 25 commits
  5. 13 Mar, 2009 9 commits
    • Gabriele Paoloni's avatar
      ppp: ppp_mp_explode() redesign · 9c705260
      Gabriele Paoloni authored 
      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: default avatarGabriele Paoloni <gabriele.paoloni@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c705260
    • Roel Kluin's avatar
      tcp: '< 0' test on unsigned · a2025b8b
      Roel Kluin authored 
      promote 'cnt' to size_t, to match 'len'.
Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2025b8b
    • Roel Kluin's avatar
      x25: '< 0' and '>= 0' test on unsigned · 8db09f26
      Roel Kluin authored 
      skb->len is an unsigned int, so the test in x25_rx_call_request() always
evaluates to true.

len in x25_sendmsg() is unsigned as well. so -ERRORS returned by x25_output()
are not noticed.
Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8db09f26
    • Denys Fedoryshchenko's avatar
      ipv4: arp announce, arp_proxy and windows ip conflict verification · 73ce7b01
      Denys Fedoryshchenko authored 
      Windows (XP at least) hosts on boot, with configured static ip, performing 
address conflict detection, which is defined in RFC3927.
Here is quote of important information:

"
An ARP announcement is identical to the ARP Probe described above, 
except    that now the sender and target IP addresses are both set 
to the host's newly selected IPv4 address. 
"

But it same time this goes wrong with RFC5227.
"
The 'sender IP address' field MUST be set to all zeroes; this is to avoid
polluting ARP caches in other hosts on the same link in the case
where the address turns out to be already in use by another host.
"

When ARP proxy configured, it must not answer to both cases, because 
it is address conflict verification in any case. For Windows it is just 
causing to detect false "ip conflict". Already there is code for RFC5227, so 
just trivially we just check also if source ip == target ip.
Signed-off-by: default avatarDenys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73ce7b01
    • Tomasz Lemiech's avatar
      tulip: Fix for MTU problems with 802.1q tagged frames · 1f8ae0a2
      Tomasz Lemiech authored 
      The original patch was submitted last year but wasn't discussed or applied
because of missing maintainer's CCs. I only fixed some formatting errors,
but as I saw tulip is very badly formatted and needs further work.

Original description:
This patch fixes MTU problem, which occurs when using 802.1q VLANs. We
should allow receiving frames of up to 1518 bytes in length, instead of
1514.

Based on patch written by Ben McKeegan for 2.4.x kernels. It is archived
at http://www.candelatech.com/~greear/vlan/howto.html#tulip
I've adjusted a few things to make it apply on 2.6.x kernels.

Tested on D-Link DFE-570TX quad-fastethernet card.
Signed-off-by: default avatarTomasz Lemiech <szpajder@staszic.waw.pl>
Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
Signed-off-by: default avatarBen McKeegan <ben@netservers.co.uk>
Acked-by: default avatarGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f8ae0a2
    • Marcin Slusarz's avatar
      phylib: convert state_queue work to delayed_work · a390d1f3
      Marcin Slusarz authored 
      It closes a race in phy_stop_machine when reprogramming of phy_timer
(from phy_state_machine) happens between del_timer_sync and cancel_work_sync.

Without this change it could lead to crash if phy_device would be freed after
phy_stop_machine (timer would fire and schedule freed work).
Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: default avatarJean Delvare <khali@linux-fr.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a390d1f3
    • Pavel Roskin's avatar
      bmac: remove unused variable bp in bmac_misc_intr() · 34cd347c
      Pavel Roskin authored 
      From: Pavel Roskin <proski@gnu.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34cd347c
    • Jan-Bernd Themann's avatar
      ehea: fix circular locking problem · 52e21b1b
      Jan-Bernd Themann authored 
      This patch fixes the circular locking problem by changing the locking strategy
concerning the logging of firmware handles.
Signed-off-by: default avatarJan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52e21b1b
    • Eric Biederman's avatar
      macvlan: Deterministic ingress packet delivery · f9ac30f0
      Eric Biederman authored 
      Changing the mac address when a macvlan device is up will leave the
device on the wrong hash chain making it impossible to receive
packets.

There is no checking of the mac address set on the macvlan.  Allowing
a misconfiguration to grab packets from the the underlying device or
another macvlan.

To resolve these problems I update the hash table of macvlans when the
mac address of a macvlan changes, and when updating the hash table
I verify that the new mac address is usable.

The result is well defined and predictable if not perfect handling of
mac vlan mac addresses.

To keep the code clear I have created a set of hash table maintenance
in macvlan so I am not open coding the hash function and the logic
needed to update the hash table all over the place.
Signed-off-by: default avatarEric Biederman <ebiederm@aristanetworks.com>
Acked-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9ac30f0