summaryrefslogtreecommitdiff
path: root/net/rds
diff options
context:
space:
mode:
authorRoss Lagerwall <ross.lagerwall@citrix.com>2018-01-11 09:36:38 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-05-30 07:50:25 +0200
commitca3108cd4764000309fdb8900262d183641eab49 (patch)
treed8708d04407b124543410029cef9ba110365efdf /net/rds
parentd6a4ef16ab138c007d6eb250ffd2e1a4a6bd6513 (diff)
xen-netfront: Fix race between device setup and open
[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ] When a netfront device is set up it registers a netdev fairly early on, before it has set up the queues and is actually usable. A userspace tool like NetworkManager will immediately try to open it and access its state as soon as it appears. The bug can be reproduced by hotplugging VIFs until the VM runs out of grant refs. It registers the netdev but fails to set up any queues (since there are no more grant refs). In the meantime, NetworkManager opens the device and the kernel crashes trying to access the queues (of which there are none). Fix this in two ways: * For initial setup, register the netdev much later, after the queues are setup. This avoids the race entirely. * During a suspend/resume cycle, the frontend reconnects to the backend and the queues are recreated. It is possible (though highly unlikely) to race with something opening the device and accessing the queues after they have been destroyed but before they have been recreated. Extend the region covered by the rtnl semaphore to protect against this race. There is a possibility that we fail to recreate the queues so check for this in the open function. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/rds')
0 files changed, 0 insertions, 0 deletions