Fix potential race condition in privileged ip_lib module
Functions like _run_iproute_{link,addr,neigh} are not atomic and
work in two steps.
First it tries to get device index and in second step calls specified
command for this device.
It might happen sometimes that device exists during first of those
steps but not exists during second step. Such case causes raising
pyroute2.NetlinkError exception which isn't properly handled in
Neutron code which uses ip_lib module.
This patch fixes it by catching pyroute2.NetlinkError exception
and raising NetworkInterfaceNotFound.
This is subclass of RuntimeError and all callers of ip_lib can handle
it properly is needed.
Reviewed: https:/ /review. openstack. org/560862 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=56324c12aa5 8ff9cf46582611b 071f3abb743ddf
Committed: https:/
Submitter: Zuul
Branch: master
commit 56324c12aa58ff9 cf46582611b071f 3abb743ddf
Author: Sławek Kapłoński <email address hidden>
Date: Thu Apr 12 13:02:56 2018 +0200
Fix potential race condition in privileged ip_lib module
Functions like _run_iproute_ {link,addr, neigh} are not atomic and NetlinkError exception which isn't properly handled in
work in two steps.
First it tries to get device index and in second step calls specified
command for this device.
It might happen sometimes that device exists during first of those
steps but not exists during second step. Such case causes raising
pyroute2.
Neutron code which uses ip_lib module.
This patch fixes it by catching pyroute2. NetlinkError exception eNotFound.
and raising NetworkInterfac
This is subclass of RuntimeError and all callers of ip_lib can handle
it properly is needed.
Change-Id: I568ef183466f5f f2f2c30ed74a7dc 52db41ba577
Closes-Bug: #1763329