Summary: | net-misc/netifrc-0.5.1: possible race condition in _add_route | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | William Hubbs <williamh> |
Component: | Current packages | Assignee: | netifrc Team <netifrc> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | wolf+gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
William Hubbs
2018-02-20 20:16:06 UTC
I need a LOT more context on where you're seeing this. _add_address calls 'ip addr add' and does check the return code. From net.lo, _add_route is called much later than _add_address. A similar thing just happened to me on a multi-homed system, though specifically with multiple IPv6 addresses and a preferred source address in ip route. Since the kernel checks whether a source address is actually configured on an interface (I'm assuming tentative addresses don't count), ip route should possibly wait until DAD is done on all addresses. Of course I cannot say whether this was the original issue, though this bug seems to describe my issue well. (In reply to Wynn Wolf Arbor from comment #2) > A similar thing just happened to me on a multi-homed system, though > specifically with multiple IPv6 addresses and a preferred source address in > ip route. > > Since the kernel checks whether a source address is actually configured on > an interface (I'm assuming tentative addresses don't count), ip route should > possibly wait until DAD is done on all addresses. > > Of course I cannot say whether this was the original issue, though this bug > seems to describe my issue well. Having seen lots of systems where DAD never finishes (the reason I added the dad_timeout knob), I feel there's a lot of risk to doing this by default. whubbs: was your original case on v4 (where this is no DAD) or v6 Wynn: you were not on the CC list, can you please see my comment 3? I have to admit that I completely forgot this bug existed, since I solved it by adding "nodad" to the affected IPv6 addresses in conf.d/net. For this particular setup I do not have a need for DAD anyway.
> Having seen lots of systems where DAD never finishes (the reason I added the
> dad_timeout knob), I feel there's a lot of risk to doing this by default.
I definitely agree with this. I haven't seen such systems yet myself, but if this is anything anyone is consistently seeing, we should not rely on DAD finishing consistently. I don't know when exactly dad_timeout was added, but having ip route wait for a maximum of dad_timeout seems like a decent workaround. Note that I have not looked at netifrc in quite a while now, though.
I have not seen any issue like this with v4 addresses in all my years.
If there's anything else I can do to help, do let me know.
|