netdev - Re: [Patch net-next] mlx5: use RCU lock in mlx5_eq_cq

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpVwO9_9d+1Ou-J7_beKyQKriA30X2wZJtAKrd0CEr2UnA@mail.gmail.com>
Date:   Wed, 6 Feb 2019 09:43:39 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [Patch net-next] mlx5: use RCU lock in mlx5_eq_cq_get()

On Wed, Feb 6, 2019 at 9:35 AM Saeed Mahameed <saeedm@...lanox.com> wrote:
>
> On Wed, 2019-02-06 at 09:15 -0800, Cong Wang wrote:
> > On Wed, Feb 6, 2019 at 8:55 AM Saeed Mahameed <saeedm@...lanox.com>
> > wrote:
> > > Hi Cong,
> > >
> > > The patch is ok to me, but i really doubt that you can hit a
> > > contention
> > > on latest upstream driver, since we already have spinlock per EQ,
> > > which
> > > means spinlock per core,  each EQ (core) msix handler can only
> > > access
> > > one spinlock (its own), so I am surprised how you got the
> > > contention,
> > > Maybe you are not running on latest upstream driver ?
> >
> > We are running 4.14 stable release. Which commit changes the game
> > here? We can consider to backport it unless it is complicated.
> >
>
> Ok, so there is no issue upstream, you are just missing the following
> patch:
>
> commit 02d92f7903647119e125b24f5470f96cee0d4b4b
> Author: Saeed Mahameed <saeedm@...lanox.com>
> Date:   Fri Jan 19 16:13:01 2018 -0800
>
>     net/mlx5: CQ Database per EQ
>
>     Before this patch the driver had one CQ database protected via one
>     spinlock, this spinlock is meant to synchronize between CQ
>     adding/removing and CQ IRQ interrupt handling.


Thanks for pointing it out! I will evaluate if we should backport it to
4.14.