On Fri, Dec 18, 2020 at 05:11:28PM +0100, Antoine Tenart wrote:
> That build issue seems unrelated to the patch. The series as a whole
> builds fine according to the same report, and this code is not modified
> by later patches.
Hi Antoine, this is a false positive report, kindly ignore this.
Sorry
Hi Jakub, Alexander,
Quoting Alexander Duyck (2020-12-19 02:41:08)
> On Fri, Dec 18, 2020 at 4:30 PM Jakub Kicinski wrote:
> >
> > Two things: (a) is the datapath not exposed to a similar problem?
> > __get_xps_queue_idx() uses dev->tc_num in a very similar fashion.
>
> I think we are shielded f
On Fri, Dec 18, 2020 at 4:30 PM Jakub Kicinski wrote:
>
> On Thu, 17 Dec 2020 17:25:18 +0100 Antoine Tenart wrote:
> > Callers to netif_set_xps_queue should take the rtnl lock. Failing to do
> > so can lead to race conditions between netdev_set_num_tc and
> > netif_set_xps_queue, triggering variou
On Thu, 17 Dec 2020 17:25:18 +0100 Antoine Tenart wrote:
> Callers to netif_set_xps_queue should take the rtnl lock. Failing to do
> so can lead to race conditions between netdev_set_num_tc and
> netif_set_xps_queue, triggering various oops:
>
> - netif_set_xps_queue uses dev->tc_num as one of the
That build issue seems unrelated to the patch. The series as a whole
builds fine according to the same report, and this code is not modified
by later patches.
It looks a lot like this report from yesterday:
https://www.spinics.net/lists/netdev/msg709132.html
Which also seemed unrelated to the cha
Hi Antoine,
I love your patch! Yet something to improve:
[auto build test ERROR on net/master]
url:
https://github.com/0day-ci/linux/commits/Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
3ae
Callers to netif_set_xps_queue should take the rtnl lock. Failing to do
so can lead to race conditions between netdev_set_num_tc and
netif_set_xps_queue, triggering various oops:
- netif_set_xps_queue uses dev->tc_num as one of the parameters to
compute the size of new_dev_maps when allocating i