forked from mirrors/linux
		
	virtio-net: disable NAPI only when enabled during XDP set
We try to disable NAPI to prevent a single XDP TX queue being used by
multiple cpus. But we don't check if device is up (NAPI is enabled),
this could result stall because of infinite wait in
napi_disable(). Fixing this by checking device state through
netif_running() before.
Fixes: 4941d472bf ("virtio-net: do not reset during XDP set")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
			
			
This commit is contained in:
		
							parent
							
								
									ecc832758a
								
							
						
					
					
						commit
						4e09ff5362
					
				
					 1 changed files with 5 additions and 3 deletions
				
			
		| 
						 | 
					@ -2185,6 +2185,7 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
 | 
				
			||||||
	}
 | 
						}
 | 
				
			||||||
 | 
					
 | 
				
			||||||
	/* Make sure NAPI is not using any XDP TX queues for RX. */
 | 
						/* Make sure NAPI is not using any XDP TX queues for RX. */
 | 
				
			||||||
 | 
						if (netif_running(dev))
 | 
				
			||||||
		for (i = 0; i < vi->max_queue_pairs; i++)
 | 
							for (i = 0; i < vi->max_queue_pairs; i++)
 | 
				
			||||||
			napi_disable(&vi->rq[i].napi);
 | 
								napi_disable(&vi->rq[i].napi);
 | 
				
			||||||
 | 
					
 | 
				
			||||||
| 
						 | 
					@ -2205,6 +2206,7 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
 | 
				
			||||||
		}
 | 
							}
 | 
				
			||||||
		if (old_prog)
 | 
							if (old_prog)
 | 
				
			||||||
			bpf_prog_put(old_prog);
 | 
								bpf_prog_put(old_prog);
 | 
				
			||||||
 | 
							if (netif_running(dev))
 | 
				
			||||||
			virtnet_napi_enable(vi->rq[i].vq, &vi->rq[i].napi);
 | 
								virtnet_napi_enable(vi->rq[i].vq, &vi->rq[i].napi);
 | 
				
			||||||
	}
 | 
						}
 | 
				
			||||||
 | 
					
 | 
				
			||||||
| 
						 | 
					
 | 
				
			||||||
		Loading…
	
		Reference in a new issue