litmus-rt.git/drivers/net/ppp, branch test

pppoe: drop pppoe device in pppoe_unbind_sock_work

2015-05-11T16:58:22+00:00

After receiving a PADT and the socket is closed, user space will no
longer drop the reference to the pppoe device.
This leads to errors like this:

[  488.570000] unregister_netdevice: waiting for eth0.2 to become free. Usage count = 2

Fixes: 287f3a943fe ("pppoe: Use workqueue to die properly when a PADT is received")
Signed-off-by: Felix Fietkau 
Signed-off-by: David S. Miller

ppp: mppe: discard late packet in stateless mode

2015-04-27T03:25:13+00:00

When PPP is used over a link which does not guarantee packet ordering,
we might get late MPPE packets. This is a problem because MPPE must be
kept synchronized and the current implementation does not drop them and
rekey 4095 times instead of 0, which is wrong.

In order to prevent rekeying about a whole count space times (~ 4095
times), drop packets which are not within the forward 4096/2 window and
increase sanity error counter.

Signed-off-by: Sylvain Rochet 
Signed-off-by: David S. Miller

ppp: mppe: sanity error path rework

2015-04-27T03:25:13+00:00

We are going to need sanity error path a little further, rework to be
able to use the sanity error path anywhere in decompressor.

Signed-off-by: Sylvain Rochet 
Signed-off-by: David S. Miller

ppp: call skb_checksum_complete_unset in ppp_receive_frame

2015-04-21T01:57:26+00:00

Call checksum_complete_unset in PPP receive to discard checksum-complete
value. PPP does not pull checksum for headers and also modifies packet
as in VJ compression.

Signed-off-by: Tom Herbert 
Signed-off-by: David S. Miller

pppoe: Lacks DST MAC address check

2015-04-20T19:26:57+00:00

A pppoe session is identified by its session ID and MAC address.
Currently pppoe does not check if the received pkg has the correct
MAC address. This is a problem when the eth I/F is in promisc mode
as then any DST MAC address is accepted.

Signed-off-by: Joakim Tjernlund 
Signed-off-by: David S. Miller

ipv4: hash net ptr into fragmentation bucket selection

2015-03-25T18:07:04+00:00

As namespaces are sometimes used with overlapping ip address ranges,
we should also use the namespace as input to the hash to select the ip
fragmentation counter bucket.

Cc: Eric Dumazet 
Cc: Flavio Leitner 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

net: Remove iocb argument from sendmsg and recvmsg

2015-03-02T18:06:31+00:00

After TIPC doesn't depend on iocb argument in its internal
implementations of sendmsg() and recvmsg() hooks defined in proto
structure, no any user is using iocb argument in them at all now.
Then we can drop the redundant iocb argument completely from kinds of
implementations of both sendmsg() and recvmsg() in the entire
networking stack.

Cc: Christoph Hellwig 
Suggested-by: Al Viro 
Signed-off-by: Ying Xue 
Signed-off-by: David S. Miller

pppoe: Use workqueue to die properly when a PADT is received

2015-03-02T05:17:31+00:00

When a PADT frame is received, the socket may not be in a good state to
close down the PPP interface. The current implementation handles this by
simply blocking all further PPP traffic, and hoping that the lack of traffic
will trigger the user to investigate.

Use schedule_work to get to a process context from which we clear down the
PPP interface, in a fashion analogous to hangup on a TTY-based PPP
interface. This causes pppd to disconnect immediately, and allows tools to
take immediate corrective action.

Note that pppd's rp_pppoe.so plugin has code in it to disable the session
when it disconnects; however, as a consequence of this patch, the session is
already disabled before rp_pppoe.so is asked to disable the session. The
result is a harmless error message:

Failed to disconnect PPPoE socket: 114 Operation already in progress

This message is safe to ignore, as long as the error is 114 Operation
already in progress; in that specific case, it means that the PPPoE session
has already been disabled before pppd tried to disable it.

Signed-off-by: Simon Farnsworth 
Tested-by: Dan Williams 
Tested-by: Christoph Schulz 
Signed-off-by: David S. Miller

ppp: deflate: never return len larger than output buffer

2015-01-29T22:50:01+00:00

When we've run out of space in the output buffer to store more data, we
will call zlib_deflate with a NULL output buffer until we've consumed
remaining input.

When this happens, olen contains the size the output buffer would have
consumed iff we'd have had enough room.

This can later cause skb_over_panic when ppp_generic skb_put()s
the returned length.

Reported-by: Iain Douglas 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller

ppp_read(): switch to skb_copy_datagram_iter()

2014-12-09T21:29:10+00:00

Signed-off-by: Al Viro