Date: Tue, 02 Jun 2020 01:39:24 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246597] Race condition in mountd Message-ID: <bug-246597-227-g0jnp7OEaK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246597-227@https.bugs.freebsd.org/bugzilla/> References: <bug-246597-227@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=3D246597 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |rmacklem@FreeBSD.org Status|New |Open --- Comment #2 from Rick Macklem <rmacklem@FreeBSD.org> --- Well, handling of SIGHUP to reload the exports file is asynchronous, so I don't think the race Patryk is referring to is affected by handling the next request before reloading the exports file. I think he is referring to a case where: - exports file is updated, sighup posted - mountd is in get_exportslist(); --> while mountd is in getexport_list()=E2=80=A6 - exports file is updated and sighup is posted - mountd completes get_exportlist(), but does not do so again, since it set got_sighup =3D 0 after the last sighup posted was handled. Patryk, do I have the above correct? Now, your fix will fix this problem, but it introduces another one. - Some file servers (Peter Eriksson) have 80000+ file systems exported on them. Yes, I did type the correct number above. He creates a separate file system for each student, etc. (Most of his servers have 20000+, but one is over 80000.) - When exports are (re)loaded on his servers, it can take minutes. I think r348590 reduced the time from something like 20minutes to 5minutes, but it is still minutes. --> What happens if a sighup is posted to mountd once every couple of minutes with your patch? All mountd does is reload exports over and over and over again (lyrics of an old Beatles toon?). The current code can suffer from this too, but it ignores sighups posted while it is in get_exportlist() which at least partially avoids this. - Part of the problem is that FreeBSD's mount command posts a sighup to mountd every time a mount is done, just in case that new file system needs to be exported. (/etc/exports hasn't changed, but it does not know if this new file system needs to be exported. I've never liked this, but it is a long standing FreeBSD tradition, so I dare not change it.;-) So, what can be done to make sure the updated exports file gets processed without just doing get_exportlist() over and over..? I think I'll post somewhere like FreeBSD-net@, since it is somewhat like a networking problem where a delay avoids congestion. An example solution might be: - time how long get_exportlist() takes. - note that sighup(s) have been posted. - do get_exportlist() again, but only after a delay at least as large as the time the last get_exportlist() took. --> That way, the updated exports would be processed, but mountd would still do other RPC work as well. --> It might be that even a delay of 1sec between get_exportlist() calls would be sufficient to allow it to do the Mount RPC requests. (There shouldn't be that many of them.) I've actually known about this for quite a while, but since I didn't have a good solution, I left it as is. --=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-246597-227-g0jnp7OEaK>