[Bug 271069] syslogd service inside client jail requires restart before server jail receives logs

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271069

Siva Mahadevan <me@svmhdvn.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #244032|0                           |1
        is obsolete|                            |
 Attachment #244033|0                           |1
        is obsolete|                            |

--- Comment #7 from Siva Mahadevan <me@svmhdvn.name> ---
Created attachment 244132
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244132&action=edit
minimal workaround

Found the root issue (all based on comment #3 with code from releng/13.2
branch, but it's still applicable in the main branch):

When the IPv6 jail is created, `/sbin/ifconfig <interface> inet6
<jail_ipv6_addr> alias` gets called to create the new IPv6 alias address. This
calls the `SIOCAIFADDR` ioctl at sbin/ifconfig/ifconfig.c:1042, which
eventually reaches sys/netinet6/in6.c:560 in the kernel. Once the new ipv6
address is created, it is marked IN6_IFF_TENTATIVE at sys/netinet6/in6.c:1177
and then later queued for Duplicate Address Detection at
sys/netinet6/in6.c:1247. However, the call to `nd6_dad_start(...)` is
asynchronous and returns immediately after starting the DAD timer at
sys/netinet6/nd6_nbr.c:1341. This causes a race condition between:
* completing the DAD process and clearing the IN6_IFF_TENTATIVE flag on the
newly created IPv6 address
* exiting the `/sbin/ifconfig` call successfully, finishing jail setup, and
starting the jail while its IPv6 address is still marked as "tentative"

By adding a sufficiently long pause at (b) in the newly attached patch, this
gives enough time for the next `nd6_timer(...)` run to find this tentative
address, complete DAD, and clear the IN6_IFF_TENTATIVE flag. This is confirmed
by adding the exact same pause at (a) instead of (b), then noticing that the
race condition still exists.

I don't have much knowledge of the IPv6 networking stack, so I'm not sure about
the proper fix here. However, it seems like there could be two possible fixes
here:
* `SIOCAIFADDR` ioctl call still returns a tentative IPv6 address pending full
DAD completion, but change the userspace `/sbin/ifconfig` tool to wait until
the tentative flag is cleared before exiting successfully
* change the `SIOCAIFADDR` ioctl handler to call the DAD routine synchronously
and return back a regular non-tentative address

-- 
You are receiving this mail because:
You are the assignee for the bug.