linux-stable.git/drivers/net, branch v3.16.82

macvlan: schedule bc_work even if error

2020-02-11T20:03:50+00:00

commit 1d7ea55668878bb350979c377fc72509dd6f5b21 upstream.

While enqueueing a broadcast skb to port->bc_queue, schedule_work()
is called to add port->bc_work, which processes the skbs in
bc_queue, to "events" work queue. If port->bc_queue is full, the
skb will be discarded and schedule_work(&port->bc_work) won't be
called. However, if port->bc_queue is full and port->bc_work is not
running or pending, port->bc_queue will keep full and schedule_work()
won't be called any more, and all broadcast skbs to macvlan will be
discarded. This case can happen:

macvlan_process_broadcast() is the pending function of port->bc_work,
it moves all the skbs in port->bc_queue to the queue "list", and
processes the skbs in "list". During this, new skbs will keep being
added to port->bc_queue in macvlan_broadcast_enqueue(), and
port->bc_queue may already full when macvlan_process_broadcast()
return. This may happen, especially when there are a lot of real-time
threads and the process is preempted.

Fix this by calling schedule_work(&port->bc_work) even if
port->bc_work is full in macvlan_broadcast_enqueue().

Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Menglong Dong 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

iwlwifi: check kasprintf() return value

2020-02-11T20:03:45+00:00

commit 5974fbb5e10b018fdbe3c3b81cb4cc54e1105ab9 upstream.

kasprintf() can fail, we should check the return value.

Fixes: 5ed540aecc2a ("iwlwifi: use mac80211 throughput trigger")
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filenames]
Signed-off-by: Ben Hutchings

bnx2x: Enable Multi-Cos feature.

2020-02-11T20:03:27+00:00

commit 069e47823fff2c634b2d46a328b5096fdc8c2a0c upstream.

FW version 7.13.15 addresses the issue in Multi-cos implementation.
This patch re-enables the Multi-Cos support in the driver.

Fixes: d1f0b5dce8fd ("bnx2x: Disable multi-cos feature.")
Signed-off-by: Sudarsana Reddy Kalluru 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: Keep calling fallback()]
Signed-off-by: Ben Hutchings

ar5523: check NULL before memcpy() in ar5523_cmd()

2020-02-11T20:03:14+00:00

commit 315cee426f87658a6799815845788fde965ddaad upstream.

memcpy() call with "idata == NULL && ilen == 0" results in undefined
behavior in ar5523_cmd(). For example, NULL is passed in callchain
"ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch
adds ilen check before memcpy() call in ar5523_cmd() to prevent an
undefined behavior.

Cc: Pontus Fuchs 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: David Laight 
Signed-off-by: Denis Efremov 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

cw1200: Fix a signedness bug in cw1200_load_firmware()

2020-02-11T20:03:14+00:00

commit 4a50d454502f1401171ff061a5424583f91266db upstream.

The "priv->hw_type" is an enum and in this context GCC will treat it
as an unsigned int so the error handling will never trigger.

Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

ath9k_hw: fix uninitialized variable data

2020-02-11T20:03:12+00:00

commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream.

Currently, data variable in ar9003_hw_thermo_cal_apply() could be
uninitialized if ar9300_otp_read_word() will fail to read the value.
Initialize data variable with 0 to prevent an undefined behavior. This
will be enough to handle error case when ar9300_otp_read_word() fails.

Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462")
Cc: Rajkumar Manoharan 
Cc: John W. Linville 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Signed-off-by: Denis Efremov 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

net: stmmac: don't stop NAPI processing when dropping a packet

2020-02-11T20:03:11+00:00

commit 07b3975352374c3f5ebb4a42ef0b253fe370542d upstream.

Currently, if we drop a packet, we exit from NAPI loop before the budget
is consumed. In some situations this will make the RX processing stall
e.g. when flood pinging the system with oversized packets, as the
errorneous packets are not dropped efficiently.

If we drop a packet, we should just continue to the next one as long as
the budget allows.

Signed-off-by: Aaro Koskinen 
Signed-off-by: David S. Miller 
[acj: backport v4.4 -stable
-adjust context]
Signed-off-by: Aviraj CJ 
Signed-off-by: Ben Hutchings

net: stmmac: use correct DMA buffer size in the RX descriptor

2020-02-11T20:03:10+00:00

commit 583e6361414903c5206258a30e5bd88cb03c0254 upstream.

We always program the maximum DMA buffer size into the receive descriptor,
although the allocated size may be less. E.g. with the default MTU size
we allocate only 1536 bytes. If somebody sends us a bigger frame, then
memory may get corrupted.

Fix by using exact buffer sizes.

Signed-off-by: Aaro Koskinen 
Signed-off-by: David S. Miller 
[acj: backport to v4.4 -stable :
- Modified patch since v4.4 driver has no support for Big endian
- Skipped the section modifying non-existent functions in dwmac4_descs.c and
dwxgmac2_descs.c ]
Signed-off-by: Aviraj CJ 
[bwh: For 3.16, don't subtract 1 from BUF_SIZE_8KiB because I already
 backported commit 8137b6ef0ce4 "net: stmmac: Fix RX packet size > 8191".
 Also fold in commit f87db4dbd52f "net: stmmac: Use bfsize1 in
 ndesc_init_rx_desc".]
Signed-off-by: Ben Hutchings

stmmac: fix oversized frame reception

2020-02-11T20:03:10+00:00

commit e527c4a769d375ac0472450c52bde29087f49cd9 upstream.

The receive skb buffers can be preallocated when the link is opened
according to mtu size.
While testing on a network environment with not standard MTU (e.g. 3000),
a panic occurred if an incoming packet had a length greater than rx skb
buffer size. This is because the HW is programmed to copy, from the DMA,
an Jumbo frame and the Sw must check if the allocated buffer is enough to
store the frame.

Signed-off-by: Alexandre TORGUE 
Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: davinci_cpdma: use dma_addr_t for DMA address

2020-02-11T20:03:10+00:00

commit 84092996673211f16ef3b942a191d7952e9dfea9 upstream.

The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:

ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
   pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,

This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.

We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Cc: Daniel Wagner 
Cc: Pavel Machek 
Signed-off-by: Ben Hutchings