On Wed, Dec 23, 2020 at 1:23 PM Antoine Tenart <aten...@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 <alexanderdu...@fb.com>
