lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 4 Jul 2016 14:34:15 +0300 From: Saeed Mahameed <saeedm@....mellanox.co.il> To: Stephen Rothwell <sfr@...b.auug.org.au> Cc: David Miller <davem@...emloft.net>, Linux Netdev List <netdev@...r.kernel.org>, linux-next@...r.kernel.org, linux-kernel <linux-kernel@...r.kernel.org>, Daniel Jurgens <danielj@...lanox.com>, Saeed Mahameed <saeedm@...lanox.com>, Yevgeny Petrilin <yevgenyp@...lanox.com> Subject: Re: linux-next: manual merge of the net-next tree with the net tree On Mon, Jul 4, 2016 at 6:07 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > drivers/net/ethernet/mellanox/mlx5/core/en_main.c > > between commit: > > 29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close") > > from the net tree and commit: > > 507f0c817f7a ("net/mlx5e: Add TXQ set max rate support") > > from the net-next tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > -- > Cheers, > Stephen Rothwell > > diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c > index 7a0dca29c642,96ec53a6a595..000000000000 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c > @@@ -39,16 -39,10 +39,17 @@@ > #include "eswitch.h" > #include "vxlan.h" > > +enum { > + MLX5_EN_QP_FLUSH_TIMEOUT_MS = 5000, > + MLX5_EN_QP_FLUSH_MSLEEP_QUANT = 20, > + MLX5_EN_QP_FLUSH_MAX_ITER = MLX5_EN_QP_FLUSH_TIMEOUT_MS / > + MLX5_EN_QP_FLUSH_MSLEEP_QUANT, > +}; > + > struct mlx5e_rq_param { > - u32 rqc[MLX5_ST_SZ_DW(rqc)]; > - struct mlx5_wq_param wq; > + u32 rqc[MLX5_ST_SZ_DW(rqc)]; > + struct mlx5_wq_param wq; > + bool am_enabled; > }; > > struct mlx5e_sq_param { > @@@ -574,8 -543,9 +582,10 @@@ static void mlx5e_close_rq(struct mlx5e > /* avoid destroying rq before mlx5e_poll_rx_cq() is done with it */ > napi_synchronize(&rq->channel->napi); > > + cancel_work_sync(&rq->am.work); > + > mlx5e_disable_rq(rq); > + mlx5e_free_rx_descs(rq); > mlx5e_destroy_rq(rq); > } > > @@@ -835,19 -810,12 +853,19 @@@ static void mlx5e_close_sq(struct mlx5e > if (mlx5e_sq_has_room_for(sq, 1)) > mlx5e_send_nop(sq, true); > > - mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, MLX5_SQC_STATE_ERR, > - false, 0); > + err = mlx5e_modify_sq(sq, MLX5_SQC_STATE_RDY, > - MLX5_SQC_STATE_ERR); > ++ MLX5_SQC_STATE_ERR, false, 0); > + if (err) > + set_bit(MLX5E_SQ_STATE_TX_TIMEOUT, &sq->state); > } Thanks Stephen, the fixup looks good. I already notified Dave on those issues and how to fix, see mail thread "Mellanox 100G mlx5 resiliency and xmit path fixes" Thanks, Saeed.
Powered by blists - more mailing lists