Date: Tue, 15 Aug 2023 21:33:51 +0000 From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 271069] syslogd service inside client jail requires restart before server jail receives logs Message-ID: <bug-271069-29815-4lMnxISpyO@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271069-29815@https.bugs.freebsd.org/bugzilla/> References: <bug-271069-29815@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271069 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=3D244132&action= =3Dedit 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. T= his 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:11= 77 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 confir= med 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 a= bout the proper fix here. However, it seems like there could be two possible fix= es here: * `SIOCAIFADDR` ioctl call still returns a tentative IPv6 address pending f= ull 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 synchronou= sly and return back a regular non-tentative address --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271069-29815-4lMnxISpyO>