linux-stable.git/drivers/net, branch v4.4.12

can: fix handling of unmodifiable configuration options

2016-06-01T19:15:50+00:00

commit bb208f144cf3f59d8f89a09a80efd04389718907 upstream.

As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
(6cfda7fbebe) it is possible to define fixed configuration options by
setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
This leads to the incovenience that the fixed configuration bits can not be
passed by netlink even when they have the correct values (e.g. non-ISO, FD).

This patch fixes that issue and not only allows fixed set bit values to be set
again but now requires(!) to provide these fixed values at configuration time.
A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
enforced by a new can_validate() function. This fix additionally removed the
inconsistency that was prohibiting the support of 'CANFD-only' controller
drivers, like the RCar CAN FD.

For this reason a new helper can_set_static_ctrlmode() has been introduced to
provide a proper interface to handle static enabled CAN controller options.

Reported-by: Ramesh Shanmugasundaram 
Signed-off-by: Oliver Hartkopp 
Reviewed-by: Ramesh Shanmugasundaram  
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions

2016-06-01T19:15:49+00:00

commit cd9e2e5d3ff148be9ea210f622ce3e8e8292fcd6 upstream.

In testing with HiKey, we found that since
commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet
frames"),
we're seeing lots of noise during network transfers:

[  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
[  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
[  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
[  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
[  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
[  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4

And network throughput ends up being pretty bursty and slow with
a overall throughput of at best ~30kB/s (where as previously we
got 1.1MB/s with the slower USB1.1 "full speed" host).

We found the issue also was reproducible on a x86_64 system,
using a "high-speed" USB2.0 port but the throughput did not
measurably drop (possibly due to the scp transfer being cpu
bound on my slow test hardware).

After lots of debugging, I found the check added in the
problematic commit seems to be calculating the offset
incorrectly.

In the normal case, in the main loop of the function, we do:
(where offset is zero, or set to "offset += (copy_length + 1) &
0xfffe" in the previous loop)
    rx->header = get_unaligned_le32(skb->data +
                                    offset);
    offset += sizeof(u32);

But the problematic patch calculates:
    offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
    rx->header = get_unaligned_le32(skb->data + offset);

Adding some debug logic to check those offset calculation used
to find rx->header, the one in problematic code is always too
large by sizeof(u32).

Thus, this patch removes the incorrect " + sizeof(u32)" addition
in the problematic calculation, and resolves the issue.

Cc: Dean Jenkins 
Cc: "David B. Robins" 
Cc: Mark Craske 
Cc: Emil Goode 
Cc: "David S. Miller" 
Cc: YongQin Liu 
Cc: Guodong Xu 
Cc: Ivan Vecera 
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Reported-by: Yongqin Liu 
Signed-off-by: John Stultz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: thunderx: avoid exposing kernel stack

2016-05-19T00:06:43+00:00

[ Upstream commit 161de2caf68c549c266e571ffba8e2163886fb10 ]

Reserved fields should be set to zero to avoid exposing
bits from the kernel stack.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_en: Fix endianness bug in IPV6 csum calculation

2016-05-19T00:06:41+00:00

[ Upstream commit 82d69203df634b4dfa765c94f60ce9482bcc44d6 ]

Use htons instead of unconditionally byte swapping nexthdr.  On a little
endian systems shifting the byte is correct behavior, but it results in
incorrect csums on big endian architectures.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Daniel Jurgens 
Reviewed-by: Carol Soto 
Tested-by: Carol Soto 
Signed-off-by: Tariq Toukan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fec: only clear a queue's work bit if the queue was emptied

2016-05-19T00:06:40+00:00

[ Upstream commit 1c021bb717a70aaeaa4b25c91f43c2aeddd922de ]

In the receive path a queue's work bit was cleared unconditionally even
if fec_enet_rx_queue only read out a part of the available packets from
the hardware. This resulted in not reading any packets in the next napi
turn and so packets were delayed or lost.

The obvious fix is to only clear a queue's bit when the queue was
emptied.

Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue")
Signed-off-by: Uwe Kleine-König 
Reviewed-by: Lucas Stach 
Tested-by: Fugang Duan 
Acked-by: Fugang Duan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_en: fix spurious timestamping callbacks

2016-05-19T00:06:37+00:00

[ Upstream commit fc96256c906362e845d848d0f6a6354450059e81 ]

When multiple skb are TX-completed in a row, we might incorrectly keep
a timestamp of a prior skb and cause extra work.

Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Reviewed-by: Eran Ben Elisha 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Fix minimum MTU

2016-05-19T00:06:36+00:00

[ Upstream commit d8edd2469ace550db707798180d1c84d81f93bca ]

Minimum MTU that can be set in Connectx4 device is 68.

This fixes the case where a user wants to set invalid MTU,
the driver will fail to satisfy this request and the interface
will stay down.

It is better to report an error and continue working with old
mtu.

Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Device's mtu field is u16 and not int

2016-05-19T00:06:36+00:00

[ Upstream commit 046339eaab26804f52f6604877f5674f70815b26 ]

For set/query MTU port firmware commands the MTU field
is 16 bits, here I changed all the "int mtu" parameters
of the functions wrapping those firmware commands to be u16.

Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

atl2: Disable unimplemented scatter/gather feature

2016-05-19T00:06:36+00:00

[ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ]

atl2 includes NETIF_F_SG in hw_features even though it has no support
for non-linear skbs.  This bug was originally harmless since the
driver does not claim to implement checksum offload and that used to
be a requirement for SG.

Now that SG and checksum offload are independent features, if you
explicitly enable SG *and* use one of the rare protocols that can use
SG without checkusm offload, this potentially leaks sensitive
information (before you notice that it just isn't working).  Therefore
this obscure bug has been designated CVE-2016-2117.

Reported-by: Justin Yackoski 
Signed-off-by: Ben Hutchings 
Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

cdc_mbim: apply "NDP to end" quirk to all Huawei devices

2016-05-19T00:06:36+00:00

[ Upstream commit c5b5343cfbc9f46af65033fa4f407d7b7d98371d ]

We now have a positive report of another Huawei device needing
this quirk: The ME906s-158 (12d1:15c1).  This is an m.2 form
factor modem with no obvious relationship to the E3372 (12d1:157d)
we already have a quirk entry for.  This is reason enough to
believe the quirk might be necessary for any number of current
and future Huawei devices.

Applying the quirk to all Huawei devices, since it is crucial
to any device affected by the firmware bug, while the impact
on non-affected devices is negligible.

The quirk can if necessary be disabled per-device by writing
N to /sys/class/net//cdc_ncm/ndp_to_end

Reported-by: Andreas Fett 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman