3.19.8-stable review
Greg Kroah-Hartman
maintainercover 3.19.8-stable review
----------------------------------
NOTE:
This is the LAST 3.19-stable release that will happen. This tree will be end-of-life after this release. Please move to 4.0.x at this point in time. This is just a last little "cleanup" release for those who are stuck on 3.19 for some odd reason. I recommend not to stay there for very long...
----------------------------------
This is the start of the stable review cycle for the 3.19.8 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun May 10 11:10:24 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.19.8-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.19.8-rc1
Boris Brezillon <[email protected]>
clk: at91: usb: fix determine_rate prototype
David S. Miller <[email protected]>
ipv4: Missing sk_nulls_node_init() in ping_unhash().
Ido Shamay <[email protected]>
net/mlx4_en: Schedule napi when RX buffers allocation fails
Hariprasad Shenai <[email protected]>
cxgb4: Fix MC1 memory offset calculation
Benjamin Poirier <[email protected]>
mlx4: Fix tx ring affinity_mask creation
Herbert Xu <[email protected]>
route: Use ipv4_mtu instead of raw rt_pmtu
Alexei Starovoitov <[email protected]>
bpf: fix 64-bit divide
-------------
Diffstat:
Makefile | 4 ++-- drivers/clk/at91/clk-usb.c | 2 -- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 2 +- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 + drivers/net/ethernet/mellanox/mlx4/en_rx.c | 26 ++++++++++++++++++++++++-- drivers/net/ethernet/mellanox/mlx4/en_tx.c | 8 +++++--- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + kernel/bpf/core.c | 12 ++++++------ net/ipv4/ping.c | 1 + net/ipv4/route.c | 5 +---- 10 files changed, 42 insertions(+), 20 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/7 bpf: fix 64-bit divide
3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexei Starovoitov <[email protected]>
[ Upstream commit 876a7ae65b86d8cec8efe7d15d050ac61116874e ]
ALU64_DIV instruction should be dividing 64-bit by 64-bit, whereas do_div() does 64-bit by 32-bit divide.
x64 and arm64 JITs correctly implement 64 by 64 unsigned divide. llvm BPF backend emits code assuming that ALU64_DIV does 64 by 64.
--- kernel/bpf/core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
kernel/bpf/core.c +6 -6
@@ -357,8 +357,8 @@ select_insn: ALU64_MOD_X:if (unlikely (SRC ==0 ))return 0 ; - tmp =DST ; -DST =do_div (tmp,SRC ); +div64_u64_rem (DST ,SRC , &tmp); +DST = tmp;CONT ; ALU_MOD_X:if (unlikely (SRC ==0 ))
@@ -367,8 +367,8 @@ select_insn:DST =do_div (tmp, (u32 )SRC );CONT ; ALU64_MOD_K: - tmp =DST ; -DST =do_div (tmp,IMM ); +div64_u64_rem (DST ,IMM , &tmp); +DST = tmp;CONT ; ALU_MOD_K: tmp = (u32 )DST ;
@@ -377,7 +377,7 @@ select_insn: ALU64_DIV_X:if (unlikely (SRC ==0 ))return 0 ; -do_div (DST ,SRC ); +DST =div64_u64 (DST ,SRC );CONT ; ALU_DIV_X:if (unlikely (SRC ==0 ))
@@ -387,7 +387,7 @@ select_insn:DST = (u32 ) tmp;CONT ; ALU64_DIV_K: -do_div (DST ,IMM ); +DST =div64_u64 (DST ,IMM );CONT ; ALU_DIV_K: tmp = (u32 )DST ;
Greg Kroah-Hartman
maintainerPATCH 2/7 route: Use ipv4_mtu instead of raw rt_pmtu
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
[ Upstream commit cb6ccf09d6b94bec4def1ac5cf4678d12b216474 ]
The commit 3cdaa5be9e81a914e633a6be7b7d2ef75b528562 ("ipv4: Don't increase PMTU with Datagram Too Big message") broke PMTU in cases where the rt_pmtu value has expired but is smaller than the new PMTU value.
This obsolete rt_pmtu then prevents the new PMTU value from being installed.
--- net/ipv4/route.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
net/ipv4/route.c +1 -4
@@ -963,10 +963,7 @@ static void __ip_rt_update_pmtu(struct rif (dst_metric_locked (dst,RTAX_MTU ))return ; -if (dst->dev->mtu < mtu) -return ; - -if (rt->rt_pmtu && rt->rt_pmtu < mtu) +if (ipv4_mtu (dst) < mtu)return ;if (mtu < ip_rt_min_pmtu)
Greg Kroah-Hartman
maintainerPATCH 3/7 mlx4: Fix tx ring affinity_mask creation
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Poirier <[email protected]>
[ Upstream commit 42eab005a5dd5d7ea2b0328aecc4d6cc0c23c9c2 ]
By default, the number of tx queues is limited by the number of online cpus in mlx4_en_get_profile(). However, this limit no longer holds after the ethtool .set_channels method has been called. In that situation, the driver may access invalid bits of certain cpumask variables when queue_index >= nr_cpu_ids.
--- drivers/net/ethernet/mellanox/mlx4/en_tx.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlx4/en_tx.c +5 -3
@@ -143,8 +143,10 @@ int mlx4_en_create_tx_ring(struct mlx4_e ring->hwtstamp_tx_type = priv->hwtstamp_config.tx_type; ring->queue_index = queue_index; -if (queue_index < priv->num_tx_rings_p_up &&cpu_online (queue_index)) -cpumask_set_cpu (queue_index, &ring->affinity_mask); +if (queue_index < priv->num_tx_rings_p_up) +cpumask_set_cpu_local_first (queue_index, + priv->mdev->dev->numa_node, + &ring->affinity_mask); *pring = ring;return 0 ;
@@ -213,7 +215,7 @@ int mlx4_en_activate_tx_ring(struct mlx4 err =mlx4_qp_to_ready (mdev->dev, &ring->wqres.mtt, &ring->context, &ring->qp, &ring->qp_state); -if (!user_prio &&cpu_online (ring->queue_index)) +if (!cpumask_empty (&ring->affinity_mask))netif_set_xps_queue (priv->dev, &ring->affinity_mask, ring->queue_index);
Greg Kroah-Hartman
maintainerPATCH 4/7 cxgb4: Fix MC1 memory offset calculation
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hariprasad Shenai <[email protected]>
[ Upstream commit 7f0b8a56c978b0a3315ac84c6cbb065413afb8e9 ]
Commit 6559a7e8296002b4 ("cxgb4: Cleanup macros so they follow the same style and look consistent") introduced a regression where reading MC1 memory in adapters where MC0 isn't present or MC0 size is not equal to MC1 size caused the adapter to crash due to incorrect computation of memoffset. Fix is to read the size of MC0 instead of MC1 for offset calculation
--- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c +1 -1
@@ -489,7 +489,7 @@ int t4_memory_rw(struct adapter *adap, i memoffset = (mtype * (edc_size *1024 *1024 )); else { mc_size =EXT_MEM0_SIZE_G (t4_read_reg (adap, -MA_EXT_MEMORY1_BAR_A )); +MA_EXT_MEMORY0_BAR_A )); memoffset = (MEM_MC0 * edc_size + mc_size) *1024 *1024 ; }
Greg Kroah-Hartman
maintainerPATCH 5/7 net/mlx4_en: Schedule napi when RX buffers allocation fails
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Shamay <[email protected]>
[ Upstream commit 07841f9d94c11afe00c0498cf242edf4075729f4 ]
When system is out of memory, refilling of RX buffers fails while the driver continue to pass the received packets to the kernel stack. At some point, when all RX buffers deplete, driver may fall into a sleep, and not recover when memory for new RX buffers is once again availible. This is because hardware does not have valid descriptors, so no interrupt will be generated for the driver to return to work in napi context. Fix it by schedule the napi poll function from stats_task delayed workqueue, as long as the allocations fail.
--- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 drivers/net/ethernet/mellanox/mlx4/en_rx.c | 26 +++++++++++++++++++++++-- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 3 files changed, 26 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx4/en_netdev.c +1 -0
@@ -1467,6 +1467,7 @@ static void mlx4_en_service_task(structif (mdev->dev->caps.flags2 &MLX4_DEV_CAP_FLAG2_TS )mlx4_en_ptp_overflow_check (mdev); +mlx4_en_recover_from_oom (priv);queue_delayed_work (mdev->workqueue, &priv->service_task,SERVICE_TASK_DELAY ); }
drivers/net/ethernet/mellanox/mlx4/en_rx.c +24 -2
@@ -240,6 +240,12 @@ static int mlx4_en_prepare_rx_desc(strucreturn mlx4_en_alloc_frags (priv, rx_desc, frags, ring->page_alloc, gfp); } +static inline bool mlx4_en_is_ring_empty (struct mlx4_en_rx_ring *ring) +{ +BUG_ON ((u32)(ring->prod - ring->cons) > ring->actual_size); +return ring->prod == ring->cons; +} +static inline void mlx4_en_update_rx_prod_db (struct mlx4_en_rx_ring *ring) { *ring->wqres.db.db =cpu_to_be32 (ring->prod &0xffff );
@@ -311,8 +317,7 @@ static void mlx4_en_free_rx_buf(struct m ring->cons, ring->prod);/* Unmap and free Rx buffers */ -BUG_ON ((u32) (ring->prod - ring->cons) > ring->actual_size); -while (ring->cons != ring->prod) { +while (!mlx4_en_is_ring_empty (ring)) { index = ring->cons & ring->size_mask;en_dbg (DRV , priv,"Processing descriptor:%d\n" , index);mlx4_en_free_rx_desc (priv, ring, index);
@@ -487,6 +492,23 @@ err_allocator:return err; } +/* We recover from out of memory by scheduling our napi poll +* function (mlx4_en_process_cq), which tries to allocate +* all missing RX buffers (call to mlx4_en_refill_rx_buffers). +*/ +void mlx4_en_recover_from_oom (struct mlx4_en_priv *priv) +{ +int ring; + +if (!priv->port_up) +return ; + +for (ring =0 ; ring < priv->rx_ring_num; ring++) { +if (mlx4_en_is_ring_empty (priv->rx_ring[ring])) +napi_reschedule (&priv->rx_cq[ring]->napi); + } +} +void mlx4_en_destroy_rx_ring (struct mlx4_en_priv *priv,struct mlx4_en_rx_ring **pring,u32 size,u16 stride)
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h +1 -0
@@ -788,6 +788,7 @@ int mlx4_en_activate_tx_ring(struct mlx4void mlx4_en_deactivate_tx_ring (struct mlx4_en_priv *priv,struct mlx4_en_tx_ring *ring);void mlx4_en_set_num_rx_rings (struct mlx4_en_dev *mdev); +void mlx4_en_recover_from_oom (struct mlx4_en_priv *priv);int mlx4_en_create_rx_ring (struct mlx4_en_priv *priv,struct mlx4_en_rx_ring **pring,u32 size,u16 stride,int node);
Greg Kroah-Hartman
maintainerPATCH 6/7 ipv4: Missing sk_nulls_node_init() in ping_unhash().
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: "David S. Miller" <[email protected]>
[ Upstream commit a134f083e79fb4c3d0a925691e732c56911b4326 ]
If we don't do that, then the poison value is left in the ->pprev backlink.
This can cause crashes if we do a disconnect, followed by a connect().
--- net/ipv4/ping.c | 1 + 1 file changed, 1 insertion(+)
net/ipv4/ping.c +1 -0
@@ -158,6 +158,7 @@ void ping_unhash(struct sock *sk)if (sk_hashed (sk)) {write_lock_bh (&ping_table.lock);hlist_nulls_del (&sk->sk_nulls_node); +sk_nulls_node_init (&sk->sk_nulls_node);sock_put (sk); isk->inet_num =0 ; isk->inet_sport =0 ;
Greg Kroah-Hartman
maintainerPATCH 7/7 clk: at91: usb: fix determine_rate prototype
In reply to Greg Kroah-Hartman3.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
Commit c67881fc890916206e723329e774391c6ed354ce is a backport of 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream commit, fixing a bug on clk rate change propagation.
But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19.
--- drivers/clk/at91/clk-usb.c | 2 -- 1 file changed, 2 deletions(-)
drivers/clk/at91/clk-usb.c +0 -2
@@ -58,8 +58,6 @@ static unsigned long at91sam9x5_clk_usb_static long at91sam9x5_clk_usb_determine_rate (struct clk_hw *hw,unsigned long rate, -unsigned long min_rate, -unsigned long max_rate,unsigned long *best_parent_rate,struct clk_hw **best_parent_hw) {
Quoted 19 lines · Greg Kroah-Hartman
----------------------------------
NOTE:This is the LAST 3.19-stable release that will happen. This tree will be end-of-life after this release. Please move to 4.0.x at this point in time. This is just a last little "cleanup" release for those who are stuck on 3.19 for some odd reason. I recommend not to stay there for very long...
----------------------------------This is the start of the stable review cycle for the 3.19.8 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun May 10 11:10:24 UTC 2015. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.19.8-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Signature · 5 lines
Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) [email protected] | (970) 217-8978
Greg Kroah-Hartman
maintainerQuoted 24 lines · Shuah Khan
Quoted 23 lines · Greg Kroah-Hartman
----------------------------------
NOTE:This is the LAST 3.19-stable release that will happen. This tree will be end-of-life after this release. Please move to 4.0.x at this point in time. This is just a last little "cleanup" release for those who are stuck on 3.19 for some odd reason. I recommend not to stay there for very long...
----------------------------------This is the start of the stable review cycle for the 3.19.8 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun May 10 11:10:24 UTC 2015. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.19.8-rc1.gzand the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing and letting me know.
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
----------------------------------
NOTE:This is the LAST 3.19-stable release that will happen. This tree will be end-of-life after this release. Please move to 4.0.x at this point in time. This is just a last little "cleanup" release for those who are stuck on 3.19 for some odd reason. I recommend not to stay there for very long...
----------------------------------
Quoted 8 lines
This is the start of the stable review cycle for the 3.19.8 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun May 10 11:10:24 UTC 2015. Anything received after that time might be too late.
Build results:
total: 125 pass: 125 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 21 lines · Guenter Roeck
Quoted 11 lines · Greg Kroah-Hartman
----------------------------------
NOTE:This is the LAST 3.19-stable release that will happen. This tree will be end-of-life after this release. Please move to 4.0.x at this point in time. This is just a last little "cleanup" release for those who are stuck on 3.19 for some odd reason. I recommend not to stay there for very long...
----------------------------------Quoted 8 lines
This is the start of the stable review cycle for the 3.19.8 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun May 10 11:10:24 UTC 2015. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 125 pass: 125 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0Details are available at http://server.roeck-us.net:8010/builders.
Great, thanks for letting me know.
greg k-h