linux-toradex.git/drivers/net, branch v4.9.107 Linux kernel for Apalis and Colibri modules net/mlx4_en: fix potential use-after-free with dma_unmap_page 2018-06-06T14:44:37+00:00 Sarah Newman srn@prgmr.com 2018-05-31T01:04:05+00:00 5d70bd5c98d0e655bde2aae2b5251bdd44df5e71 [ Not relevant upstream, therefore no upstream commit. ] To fix, unmap the page as soon as possible. When swiotlb is in use, calling dma_unmap_page means that the original page mapped with dma_map_page must still be valid, as swiotlb will copy data from its internal cache back to the originally requested DMA location. When GRO is enabled, before this patch all references to the original frag may be put and the page freed before dma_unmap_page in mlx4_en_free_frag is called. It is possible there is a path where the use-after-free occurs even with GRO disabled, but this has not been observed so far. The bug can be trivially detected by doing the following: * Compile the kernel with DEBUG_PAGEALLOC * Run the kernel as a Xen Dom0 * Leave GRO enabled on the interface * Run a 10 second or more test with iperf over the interface. This bug was likely introduced in commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"), first part of u3.6. It was incidentally fixed in commit 34db548bfb95 ("mlx4: add page recycling in receive path"), first part of v4.12. This version applies to the v4.9 series. Signed-off-by: Sarah Newman <srn@prgmr.com> Tested-by: Sarah Newman <srn@prgmr.com> Cc: Tariq Toukan <tariqt@mellanox.com> Cc: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Not relevant upstream, therefore no upstream commit. ]

To fix, unmap the page as soon as possible.

When swiotlb is in use, calling dma_unmap_page means that
the original page mapped with dma_map_page must still be valid,
as swiotlb will copy data from its internal cache back to the
originally requested DMA location.

When GRO is enabled, before this patch all references to the
original frag may be put and the page freed before dma_unmap_page
in mlx4_en_free_frag is called.

It is possible there is a path where the use-after-free occurs
even with GRO disabled, but this has not been observed so far.

The bug can be trivially detected by doing the following:

* Compile the kernel with DEBUG_PAGEALLOC
* Run the kernel as a Xen Dom0
* Leave GRO enabled on the interface
* Run a 10 second or more test with iperf over the interface.

This bug was likely introduced in
commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"),
first part of u3.6.

It was incidentally fixed in
commit 34db548bfb95 ("mlx4: add page recycling in receive path"),
first part of v4.12.

This version applies to the v4.9 series.

Signed-off-by: Sarah Newman <srn@prgmr.com>
Tested-by: Sarah Newman <srn@prgmr.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
Cc: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c 2018-06-06T14:44:33+00:00 Matthias Kaehlcke mka@chromium.org 2018-02-09T00:57:12+00:00 fd9c9fff2fee867a42d83eca65eb5767d1837193 commit fb239c1209bb0f0b4830cc72507cc2f2d63fadbd upstream. In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned unmodified. The self-assignment causes clang to raise the following warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13: error: explicitly assigning value of variable of type 'u32' (aka 'unsigned int') to itself [-Werror,-Wself-assign] writeVal = writeVal; Delete the branch with the self-assignment. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fb239c1209bb0f0b4830cc72507cc2f2d63fadbd upstream.

In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
is assigned to itself in an if ... else statement, apparently only to
document that the branch condition is handled and that a previously read
value should be returned unmodified. The self-assignment causes clang to
raise the following warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
  error: explicitly assigning value of variable of type 'u32'
    (aka 'unsigned int') to itself [-Werror,-Wself-assign]
  writeVal = writeVal;

Delete the branch with the self-assignment.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: stmmac: ensure that the MSS desc is the last desc to set the own bit 2018-05-30T05:50:49+00:00 Niklas Cassel niklas.cassel@axis.com 2018-02-26T21:47:06+00:00 5b3b32d061477e99d0805197930ad60dd51909d6 [ Upstream commit 15d2ee42a3087089e73ad52fd8c1b37ab496b87c ] A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory. There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc. However, in the rare case that MSS changes, there will be a MSS context descriptor in front of the regular DMA descriptors: <MSS desc> <- DMA Next Descriptor <First Desc> <desc n> <Last Desc> Thus, for this special case, we need a dma_wmb() after prepare_tso_tx_desc()/before writing the own bit to the MSS desc, so that we flush the write to TDES3 for First Desc, in order to ensure that the MSS descriptor is the last descriptor to set the own bit. Signed-off-by: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 15d2ee42a3087089e73ad52fd8c1b37ab496b87c ]

A dma_wmb() is used to guarantee the ordering, with respect to
other writes, to cache coherent DMA memory.

There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which
ensures that TDES0/1/2 is written before TDES3 (which contains the own
bit), for First Desc.

However, in the rare case that MSS changes, there will be a MSS
context descriptor in front of the regular DMA descriptors:

<MSS desc> <- DMA Next Descriptor
<First Desc>
<desc n>
<Last Desc>

Thus, for this special case, we need a dma_wmb()
after prepare_tso_tx_desc()/before writing the own bit to the MSS desc,
so that we flush the write to TDES3 for First Desc,
in order to ensure that the MSS descriptor is the last descriptor to
set the own bit.

Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: stmmac: ensure that the device has released ownership before reading data 2018-05-30T05:50:48+00:00 Niklas Cassel niklas.cassel@axis.com 2018-02-26T21:47:08+00:00 82aad32b4aad92244bc7b8e4cd1210253785fe03 [ Upstream commit a6b25da5e7ba212af5826a662e6a035a79bffabd ] According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit. This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields, e.g. reading the tx hardware timestamp (if PTP is enabled). Signed-off-by: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit a6b25da5e7ba212af5826a662e6a035a79bffabd ]

According to Documentation/memory-barriers.txt, we need to use a
dma_rmb() after reading the status/own bit, to ensure that all
descriptor fields are read after reading the own bit.

This way, we ensure that the DMA engine is done with the DMA
descriptor before we read the other descriptor fields, e.g. reading
the tx hardware timestamp (if PTP is enabled).

Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
enic: enable rq before updating rq descriptors 2018-05-30T05:50:48+00:00 Govindarajulu Varadarajan gvaradar@cisco.com 2018-03-01T19:07:23+00:00 92ff7ff0318f3c38394d36629084a19ea0e61a23 [ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ] rq should be enabled before posting the buffers to rq desc. If not hw sees stale value and casuses DMAR errors. Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]

rq should be enabled before posting the buffers to rq desc. If not hw sees
stale value and casuses DMAR errors.

Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cxgb4: Fix queue free path of ULD drivers 2018-05-30T05:50:45+00:00 Arjun Vynipadath arjun@chelsio.com 2018-03-15T12:04:14+00:00 494ce7e6afff5532f31c661cc7432ed9748452e7 [ Upstream commit d7cb44496a9bb458632cb3c18acb08949c210448 ] Setting sge_uld_rxq_info to NULL in free_queues_uld(). We are referencing sge_uld_rxq_info in cxgb_up(). This will fix a panic when interface is brought up after a ULDq creation failure. Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation of resources for ULD) Signed-off-by: Arjun Vynipadath <arjun@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudhar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit d7cb44496a9bb458632cb3c18acb08949c210448 ]

Setting sge_uld_rxq_info to NULL in free_queues_uld().
We are referencing sge_uld_rxq_info in cxgb_up(). This
will fix a panic when interface is brought up after a
ULDq creation failure.

Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation
       of resources for ULD)
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudhar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS 2018-05-30T05:50:44+00:00 Jay Vosburgh jay.vosburgh@canonical.com 2018-03-22T14:42:41+00:00 ebfab1f2ddf3540cc1ba6af1671eae23c1ebc905 [ Upstream commit bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ] The operstate update logic will leave an interface in the default UNKNOWN operstate if the interface carrier state never changes from the default carrier up state set at creation. This includes the case of an explicit call to netif_carrier_on, as the carrier on to on transition has no effect on operstate. This affects virtio-net for the case that the virtio peer does not support VIRTIO_NET_F_STATUS (the feature that provides carrier state updates). Without this feature, the virtio specification states that "the link should be assumed active," so, logically, the operstate should be UP instead of UNKNOWN. This has impact on user space applications that use the operstate to make availability decisions for the interface. Resolve this by changing the virtio probe logic slightly to call netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS cases, and then the existing call to netif_carrier_on for the "without" case will cause an operstate transition. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ]

The operstate update logic will leave an interface in the
default UNKNOWN operstate if the interface carrier state never changes
from the default carrier up state set at creation.  This includes the
case of an explicit call to netif_carrier_on, as the carrier on to on
transition has no effect on operstate.

	This affects virtio-net for the case that the virtio peer does
not support VIRTIO_NET_F_STATUS (the feature that provides carrier state
updates).  Without this feature, the virtio specification states that
"the link should be assumed active," so, logically, the operstate should
be UP instead of UNKNOWN.  This has impact on user space applications
that use the operstate to make availability decisions for the interface.

	Resolve this by changing the virtio probe logic slightly to call
netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS
cases, and then the existing call to netif_carrier_on for the "without"
case will cause an operstate transition.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cxgb4: Setup FW queues before registering netdev 2018-05-30T05:50:44+00:00 Arjun Vynipadath arjun@chelsio.com 2018-03-23T09:55:10+00:00 79ad08dae99b978b6d1567f746076272cadefc38 [ Upstream commit 843bd7db79c861b49e2912d723625f5fa8e94502 ] When NetworkManager is enabled, there are chances that interface up is called even before probe completes. This means we have not yet allocated the FW sge queues, hence rest of ingress queue allocation wont be proper. Fix this by calling setup_fw_sge_queues() before register_netdev(). Fixes: 0fbc81b3ad51 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's') Signed-off-by: Arjun Vynipadath <arjun@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 843bd7db79c861b49e2912d723625f5fa8e94502 ]

When NetworkManager is enabled, there are chances that interface up
is called even before probe completes. This means we have not yet
allocated the FW sge queues, hence rest of ingress queue allocation
wont be proper. Fix this by calling setup_fw_sge_queues() before
register_netdev().

Fixes: 0fbc81b3ad51 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's')
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk) 2018-05-30T05:50:44+00:00 Karthikeyan Periyasamy periyasa@codeaurora.org 2018-03-12T11:39:40+00:00 e63ff84eb09953c4028fc450fe2c4c0103cf7ba0 [ Upstream commit 8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ] When attempt to run worker (ath10k_sta_rc_update_wk) after the station object (ieee80211_sta) delete will trigger the kernel panic. This problem arise in AP + Mesh configuration, Where the current node AP VAP and neighbor node mesh VAP MAC address are same. When the current mesh node try to establish the mesh link with neighbor node, driver peer creation for the neighbor mesh node fails due to duplication MAC address. Already the AP VAP created with same MAC address. It is caused by the following scenario steps. Steps: 1. In above condition, ath10k driver sta_state callback (ath10k_sta_state) fails to do the state change for a station from IEEE80211_STA_NOTEXIST to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is called from ieee80211_add_station() to handle the new station (neighbor mesh node) request from the wpa_supplicant. 2. Concurrently ath10k receive the sta_rc_update callback notification from the mesh_neighbour_update() to handle the beacon frames of the above neighbor mesh node. since its atomic callback, ath10k driver queue the work (ath10k_sta_rc_update_wk) to handle rc update. 3. Due to driver sta_state callback fails (step 1), mac80211 free the station object. 4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access the station object which is already deleted. so it will trigger kernel panic. Added the peer exist check in sta_rc_update callback before queue the work. Kernel Panic log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1 task: dcef0000 ti: d72b6000 task.ti: d72b6000 PC is at pwq_activate_delayed_work+0x10/0x40 LR is at pwq_activate_delayed_work+0xc/0x40 pc : [<c023f988>] lr : [<c023f984>] psr: 40000193 sp : d72b7f18 ip : 0000007a fp : d72b6000 r10: 00000000 r9 : dd404414 r8 : d8c31998 r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300 r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 595bc06a DAC: 00000015 ... Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238) Stack: (0xd72b7f18 to 0xd72b8000) 7f00: 00000001 dcee1300 7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089 7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000 7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000 7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340 7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4) [<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360) [<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec) [<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34) Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs Rebooting in 3 seconds.. Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ]

When attempt to run worker (ath10k_sta_rc_update_wk) after the station object
(ieee80211_sta) delete will trigger the kernel panic.

This problem arise in AP + Mesh configuration, Where the current node AP VAP
and neighbor node mesh VAP MAC address are same. When the current mesh node
try to establish the mesh link with neighbor node, driver peer creation for
the neighbor mesh node fails due to duplication MAC address. Already the AP
VAP created with same MAC address.

It is caused by the following scenario steps.

Steps:
1. In above condition, ath10k driver sta_state callback (ath10k_sta_state)
   fails to do the state change for a station from IEEE80211_STA_NOTEXIST
   to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is
   called from ieee80211_add_station() to handle the new station
   (neighbor mesh node) request from the wpa_supplicant.
2. Concurrently ath10k receive the sta_rc_update callback notification from
   the mesh_neighbour_update() to handle the beacon frames of the above
   neighbor mesh node. since its atomic callback, ath10k driver queue the
   work (ath10k_sta_rc_update_wk) to handle rc update.
3. Due to driver sta_state callback fails (step 1), mac80211 free the station
   object.
4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access
   the station object which is already deleted. so it will trigger kernel
   panic.

Added the peer exist check in sta_rc_update callback before queue the work.

Kernel Panic log:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0204000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1
task: dcef0000 ti: d72b6000 task.ti: d72b6000
PC is at pwq_activate_delayed_work+0x10/0x40
LR is at pwq_activate_delayed_work+0xc/0x40
pc : [<c023f988>]    lr : [<c023f984>]    psr: 40000193
sp : d72b7f18  ip : 0000007a  fp : d72b6000
r10: 00000000  r9 : dd404414  r8 : d8c31998
r7 : d72b6038  r6 : 00000004  r5 : d4907ec8  r4 : dcee1300
r3 : ffffffe0  r2 : 00000000  r1 : 00000001  r0 : 00000000
Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 595bc06a  DAC: 00000015
...
Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238)
Stack: (0xd72b7f18 to 0xd72b8000)
7f00:                                                       00000001 dcee1300
7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089
7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000
7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000
7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340
7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4)
[<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360)
[<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec)
[<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34)
Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs
Rebooting in 3 seconds..

Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/mlx5: Protect from command bit overflow 2018-05-30T05:50:43+00:00 Leon Romanovsky leonro@mellanox.com 2018-01-02T14:49:56+00:00 6d59a4a6df2c9e30242ab3e02b436fc30cdf5b34 [ Upstream commit 957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ] The system with CONFIG_UBSAN enabled on produces the following error during driver initialization. The reason to it that max_reg_cmds can be larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long. ================================================================================ UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42 signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0xe9/0x18f ? dma_virt_alloc+0x81/0x81 ubsan_epilogue+0xe/0x4e handle_overflow+0x187/0x20c mlx5_cmd_init+0x73a/0x12b0 mlx5_load_one+0x1c3d/0x1d30 init_one+0xd02/0xf10 pci_device_probe+0x26c/0x3b0 driver_probe_device+0x622/0xb40 __driver_attach+0x175/0x1b0 bus_for_each_dev+0xef/0x190 bus_add_driver+0x2db/0x490 driver_register+0x16b/0x1e0 __pci_register_driver+0x177/0x1b0 init+0x6d/0x92 do_one_initcall+0x15b/0x270 kernel_init_freeable+0x2d8/0x3d0 kernel_init+0x14/0x190 ret_from_fork+0x24/0x30 ================================================================================ Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ]

The system with CONFIG_UBSAN enabled on produces the following error
during driver initialization. The reason to it that max_reg_cmds can be
larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long.

================================================================================
UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42
signed integer overflow:
-2147483648 - 1 cannot be represented in type 'int'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
 dump_stack+0xe9/0x18f
 ? dma_virt_alloc+0x81/0x81
 ubsan_epilogue+0xe/0x4e
 handle_overflow+0x187/0x20c
 mlx5_cmd_init+0x73a/0x12b0
 mlx5_load_one+0x1c3d/0x1d30
 init_one+0xd02/0xf10
 pci_device_probe+0x26c/0x3b0
 driver_probe_device+0x622/0xb40
 __driver_attach+0x175/0x1b0
 bus_for_each_dev+0xef/0x190
 bus_add_driver+0x2db/0x490
 driver_register+0x16b/0x1e0
 __pci_register_driver+0x177/0x1b0
 init+0x6d/0x92
 do_one_initcall+0x15b/0x270
 kernel_init_freeable+0x2d8/0x3d0
 kernel_init+0x14/0x190
 ret_from_fork+0x24/0x30
================================================================================

Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>