netdev - Re: [PATCH net v2 1/3] net: fix race conditions in xps by locking the maps and dev->tc

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: <20201223121110.65effe06@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 23 Dec 2020 12:11:10 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Antoine Tenart <atenart@...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

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.

> - 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?
🤔

> > We need to do something about the fact that with sysfs taking
> > rtnl_lock xps_map_mutex is now entirely pointless. I guess its value
> > eroded over the years since Tom's initial design so we can just get
> > rid of it.  
> 
> We should be able to remove the mutex (I'll double check as more
> functions are involved). If so, I can send a patch to net-next.