| Message ID | 20201223212323.3603139-1-atenart@kernel.org |
|---|---|
| Headers | show |
| Series | net-sysfs: fix race conditions in the xps code | expand |
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!