mbox series

[net,v3,0/4] net-sysfs: fix race conditions in the xps code

Message ID 20201223212323.3603139-1-atenart@kernel.org (mailing list archive)
Headers show
Series net-sysfs: fix race conditions in the xps code | expand

Message

Antoine Tenart Dec. 23, 2020, 9:23 p.m. UTC
Hello all,

This series fixes race conditions in the xps code, where out of bound
accesses can occur when dev->num_tc is updated, triggering oops. The
root cause is linked to locking issues. An explanation is given in each
of the commit logs.

We had a discussion on the v1 of this series about using the xps_map
mutex instead of the rtnl lock. While that seemed a better compromise,
v2 showed the added complexity wasn't best for fixes. So we decided to
go back to v1 and use the rtnl lock.

Because of this, the only differences between v1 and v3 are improvements
in the commit messages.

Thanks!
Antoine

Antoine Tenart (4):
  net-sysfs: take the rtnl lock when storing xps_cpus
  net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc
  net-sysfs: take the rtnl lock when storing xps_rxqs
  net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc

 net/core/net-sysfs.c | 65 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 53 insertions(+), 12 deletions(-)

Comments

Alexander Duyck Dec. 23, 2020, 11:26 p.m. UTC | #1
On Wed, Dec 23, 2020 at 1:23 PM Antoine Tenart <atenart@kernel.org> wrote:
>
> Hello all,
>
> This series fixes race conditions in the xps code, where out of bound
> accesses can occur when dev->num_tc is updated, triggering oops. The
> root cause is linked to locking issues. An explanation is given in each
> of the commit logs.
>
> We had a discussion on the v1 of this series about using the xps_map
> mutex instead of the rtnl lock. While that seemed a better compromise,
> v2 showed the added complexity wasn't best for fixes. So we decided to
> go back to v1 and use the rtnl lock.
>
> Because of this, the only differences between v1 and v3 are improvements
> in the commit messages.
>
> Thanks!
> Antoine
>
> Antoine Tenart (4):
>   net-sysfs: take the rtnl lock when storing xps_cpus
>   net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc
>   net-sysfs: take the rtnl lock when storing xps_rxqs
>   net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc
>
>  net/core/net-sysfs.c | 65 ++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 53 insertions(+), 12 deletions(-)
>

The series looks fine to me. Not the prettiest in the case of showing
the maps, but I don't think much can be done about that since we have
to return an error type and release the rtnl_lock.

Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Jakub Kicinski Dec. 28, 2020, 9:29 p.m. UTC | #2
On Wed, 23 Dec 2020 15:26:08 -0800 Alexander Duyck wrote:
> On Wed, Dec 23, 2020 at 1:23 PM Antoine Tenart <atenart@kernel.org> wrote:
> >
> > Hello all,
> >
> > This series fixes race conditions in the xps code, where out of bound
> > accesses can occur when dev->num_tc is updated, triggering oops. The
> > root cause is linked to locking issues. An explanation is given in each
> > of the commit logs.
> >
> > We had a discussion on the v1 of this series about using the xps_map
> > mutex instead of the rtnl lock. While that seemed a better compromise,
> > v2 showed the added complexity wasn't best for fixes. So we decided to
> > go back to v1 and use the rtnl lock.
> >
> > Because of this, the only differences between v1 and v3 are improvements
> > in the commit messages.
> >
> > Thanks!
> > Antoine
> >
> > Antoine Tenart (4):
> >   net-sysfs: take the rtnl lock when storing xps_cpus
> >   net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc
> >   net-sysfs: take the rtnl lock when storing xps_rxqs
> >   net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc
> >
> >  net/core/net-sysfs.c | 65 ++++++++++++++++++++++++++++++++++++--------
> >  1 file changed, 53 insertions(+), 12 deletions(-)
> >  
> 
> The series looks fine to me. Not the prettiest in the case of showing
> the maps, but I don't think much can be done about that since we have
> to return an error type and release the rtnl_lock.
> 
> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>

Applied, thanks!