[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <160875571511.1783433.16922263997505181889@kwain.local>
Date: Wed, 23 Dec 2020 21:35:15 +0100
From: Antoine Tenart <atenart@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Alexander Duyck <alexander.duyck@...il.com>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net v2 1/3] net: fix race conditions in xps by locking the maps and dev->tc_num
Quoting Jakub Kicinski (2020-12-23 21:11:10)
> On Wed, 23 Dec 2020 20:36:33 +0100 Antoine Tenart wrote:
> > Quoting Jakub Kicinski (2020-12-23 19:27:29)
> > > On Tue, 22 Dec 2020 08:12:28 -0800 Alexander Duyck wrote:
> > > > On Tue, Dec 22, 2020 at 1:21 AM Antoine Tenart <atenart@...nel.org> wrote:
> > > >
> > > > > If I understood correctly, as things are a bit too complex now, you
> > > > > would prefer that we go for the solution proposed in v1?
> > > >
> > > > Yeah, that is what I am thinking. Basically we just need to make sure
> > > > the num_tc cannot be updated while we are reading the other values.
> > >
> > > Yeah, okay, as much as I dislike this approach 300 lines may be a little
> > > too large for stable.
> > >
> > > > > I can still do the code factoring for the 2 sysfs show operations, but
> > > > > that would then target net-next and would be in a different series. So I
> > > > > believe we'll use the patches of v1, unmodified.
> > >
> > > Are you saying just patch 3 for net-next?
> >
> > The idea would be to:
> >
> > - For net, to take all 4 patches from v1. If so, do I need to resend
> > them?
>
> Yes, please.
Will do.
> > - For net-next, to resend patches 2 and 3 from v2 (they'll have to be
> > slightly reworked, to take into account the review from Alexander and
> > the rtnl lock). The patches can be sent once the ones for net land in
> > net-next.
>
> If the direction is to remove xps_map_mutex, why would we need patch 2?
> 🤔
Only the patches for net are needed to fix the race conditions.
In addition to use the xps_map mutex, patches 2 and 3 from v2 factorize
the code into a single function, as xps_cpus_show and xps_rxqs_show
share the same logic. That would improve maintainability, but isn't
mandatory.
Sorry, it was not very clear...
Antoine
Powered by blists - more mailing lists