{"push_id":564830484,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"703bf08d72ef617b212632e038a93be0d00e879f","before":"c284a3f07339b344c40b70ad64d0d554d8738f84","commits":[{"sha":"703bf08d72ef617b212632e038a93be0d00e879f","author":{"email":"625169824b719df98706d88646d0aae6f368ae4d@cloudius-systems.com","name":"Nadav Har'El"},"message":"Avoid crash during exit()\n\nAs reported in issue #580 (and also earlier in issue #374), sometimes OSv\ncrashes during a call to exit(), with the message \"exception nested too\ndeeply\" usually printed. The \"shutdown\" REST API can probably cause\na similar issue, though this was not reported in practice.\n\nThe problem is that exit(), calling osv::shutdown(), forcibly unmounts the\nfilesystem, but other threads might still be running code from executables\nmapped from files. If these threads happen to run after osv::shutdown()\nunmounts the filesystem but before it powers off the VM, they can cause\nOSv to crash, a crash which is usually accompanied by a \"exception nested\ntoo deeply\" message, as the page-fault handler itself crashes.\n\nA complete solution of this problem is difficult - in Unix it is usually\nsolved by killing all user processes before unmounting the filesystem,\nbut in OSv we have no reliable method of killing threads. The closest\napproximation is what I do in this patch - use thread::unsafe_stop()\nto stop all application threads (presumably, these would be the threads\nrunning code from the filesystem).\n\nThis technique will usually work - in particular it eliminates the crashes\nreported in issue #580. But is not an entirely reliable solution - if an\napplication thread happens to hold a critical OSv mutex while it is stopped,\nthis can deadlock the entire system. This should be a rare problem (a\nreasonable application is unlikely to call exit() while its other threads are\nbusy doing important work), but we should nevertheless re-consider this\nworkaround in the future.\n\nOne idea we can consider is not to preemptively stop the application\nthreads before unmounting (as we do in this patch). Instead, we can leave\nthese threads running, and in the page-fault handler code recognize\nthis case (the backing file has been unmounted), and stop this thread\nonly at at that point. It still remains to be seen whether that technique\ncan completely avoid deadlocks (theoretically, we can be holding a mutex\nwhile a page fault happens...) or other types of horrible crashes.\n\nFixes #580.\nFixed #374.\n\nSigned-off-by: Nadav Har'El <nyh@cloudius-systems.com>\nSigned-off-by: Pekka Enberg <penberg@cloudius-systems.com>","distinct":true,"url":"https://api.github.com/repos/vsrinivas/osv/commits/703bf08d72ef617b212632e038a93be0d00e879f"}]}