linux-toradex.git/net/atm/br2684.c, branch v3.19

net: set name_assign_type in alloc_netdev()

2014-07-15T23:12:48+00:00

Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.

Coccinelle patch:

@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@

(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)

v9: move comments here from the wrong commit

Signed-off-by: Tom Gundersen 
Reviewed-by: David Herrmann 
Signed-off-by: David S. Miller

br2684: allow assign only on a connected socket

2012-12-02T00:05:19+00:00

The br2684 does not check if used vcc is in connected state,
causing potential Oops in pppoatm_send() when vcc->send() is called
on not fully connected socket.

Now br2684 can be assigned only on connected sockets; otherwise
-EINVAL error is returned.

Signed-off-by: Krzysztof Mazur 
Signed-off-by: David Woodhouse

br2684: fix module_put() race

2012-12-02T00:05:16+00:00

The br2684 code used module_put() during unassignment from vcc with
hope that we have BKL. This assumption is no longer true.

Now owner field in atmvcc is used to move this module_put()
to vcc_destroy_socket().

Signed-off-by: David Woodhouse 
Acked-by: Krzysztof Mazur

br2684: don't send frames on not-ready vcc

2012-12-02T00:05:14+00:00

Avoid submitting packets to a vcc which is being closed. Things go badly
wrong when the ->pop method gets later called after everything's been
torn down.

Use the ATM socket lock for synchronisation with vcc_destroy_socket(),
which clears the ATM_VF_READY bit under the same lock. Otherwise, we
could end up submitting a packet to the device driver even after its
->ops->close method has been called. And it could call the vcc's ->pop
method after the protocol has been shut down. Which leads to a panic.

Signed-off-by: David Woodhouse 
Acked-by: Krzysztof Mazur

atm: br2684: Fix excessive queue bloat

2012-11-26T22:13:56+00:00

There's really no excuse for an additional wmem_default of buffering
between the netdev queue and the ATM device. Two packets (one in-flight,
and one ready to send) ought to be fine. It's not as if it should take
long to get another from the netdev queue when we need it.

If necessary we can make the queue space configurable later, but I don't
think it's likely to be necessary.

cf. commit 9d02daf754238adac48fa075ee79e7edd3d79ed3 (pppoatm: Fix
excessive queue bloat) which did something very similar for PPPoATM.

Note that there is a tremendously unlikely race condition which may
result in qspace temporarily going negative. If a CPU running the
br2684_pop() function goes off into the weeds for a long period of time
after incrementing qspace to 1, but before calling netdev_wake_queue()...
and another CPU ends up calling br2684_start_xmit() and *stopping* the
queue again before the first CPU comes back, the netdev queue could
end up being woken when qspace has already reached zero.

An alternative approach to coping with this race would be to check in
br2684_start_xmit() for qspace==0 and return NETDEV_TX_BUSY, but just
using '> 0' and '< 1' for comparison instead of '== 0' and '!= 0' is
simpler. It just warranted a mention of *why* we do it that way...

Move the call to atmvcc->send() to happen *after* the accounting and
potentially stopping the netdev queue, in br2684_xmit_vcc(). This matters
if the ->send() call suffers an immediate failure, because it'll call
br2684_pop() with the offending skb before returning. We want that to
happen *after* we've done the initial accounting for the packet in
question. Also make it return an appropriate success/failure indication
while we're at it.

Tested by running 'ping -l 1000 bottomless.aaisp.net.uk' from within my
network, with only a single PPPoE-over-BR2684 link running. And after
setting txqueuelen on the nas0 interface to something low (5, in fact).
Before the patch, we'd see about 15 packets being queued and a resulting
latency of ~56ms being reached. After the patch, we see only about 8,
which is fairly much what we expect. And a max latency of ~36ms. On this
OpenWRT box, wmem_default is 163840.

Signed-off-by: David Woodhouse 
Reviewed-by: Krzysztof Mazur 
Signed-off-by: David S. Miller

net: cleanup unsigned to unsigned int

2012-04-15T16:44:40+00:00

Use of "unsigned int" is preferred to bare "unsigned" in net tree.

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

atm: br2684: Avoid alignment issues

2011-11-29T05:28:06+00:00

Use memcmp() instead of cast to u16 when checking the PAD field.

Signed-off-by: Pascal Hambourg 
Signed-off-by: chas williams - CONTRACTOR 
Signed-off-by: David S. Miller

atm: br2684: Make headroom and hard_header_len depend on the payload type

2011-11-29T05:28:06+00:00

Routed payload requires less headroom than bridged payload.
So do not reallocate headroom if not needed.
Also, add worst case AAL5 overhead to netdev->hard_header_len.

Signed-off-by: Pascal Hambourg 
Signed-off-by: chas williams - CONTRACTOR 
Signed-off-by: David S. Miller

atm: Introduce vcc_process_recv_queue

2011-11-22T21:15:42+00:00

This function moves the implementation found in the clip and br2684
modules to common code, correctly unlinks the skb from the queue
before pushing it and makes pppoatm use it.

Signed-off-by: Jorge Boncompte [DTI2] 
Signed-off-by: David S. Miller

atm: br2684: Do not move counters backwards

2011-11-22T21:15:22+00:00

This snippet has caused several bugs in the past, and I don't see the
point on substracting the skb len from netdev stats.

Signed-off-by: Jorge Boncompte [DTI2] 
Signed-off-by: David S. Miller