Race：在 OSX 中卸载 kext 期间的回调和删除回调答案

【问题标题】：Race: callbacks and removing callbacks during unload of kext in OSXRace：在 OSX 中卸载 kext 期间的回调和删除回调
【发布时间】：2016-06-28 19:29:41
【问题描述】：

建立/删除回调（例如 kauth_unlisten_scope）和回调本身（在 xnu 代码库中，是的，我知道，它已经过时了）之间似乎没有同步。这将跟踪/排出回调和与扩展本身的调用同步的负担。但这也是有问题的，因为有一个窗口指出线程已退出回调并实际上从扩展代码中返回。

是否有任何模式可以正确避免这场比赛？或者，是否有任何来自 Apple 的文档表明他们已正确同步？

【问题讨论】：

标签： macos kernel xnu kernel-extension

【解决方案1】：

据我所知，没有 100% 可靠的方法可以防止 kauth 回调注销竞争条件； API 设计得很糟糕。 Apple 自己实现/推荐了一个简单的基于原子计数器的机制，您可以在 Kauth-O-Rama example 中看到它。在 KauthORama.c 源文件中搜索 gActivationCount。在回调中，线程在递增之前或递减之后运行代码的可能性仍然很小，但我从未见过由此导致的崩溃。

【讨论】：

谢谢！我知道 kauth-o-rama 示例，但是添加仍然有比赛的一秒钟延迟让我感到烦恼。根据我的经验，“你从未见过”意味着我的客户会在第 0 天击中它。墨菲疯了。
是的，它也困扰着我，但如果你看一下这个例子，那里的评论基本上承认你不能干净地做到这一点给定现有的 API，而且它只是坏了。您可以归档雷达。我想问题也是您计划在生产中卸载 kext 的频率。如果它一直发生，那么是的，人们可能会碰到它。在实践中，通常很少会像这样卸载 kext。
是的，这很罕见，但我是“如果可以发生，那么我应该解决它”，说服...
如果您确实找到了方法，请告诉我们。不过，我不会为此失眠——引用编写 Kauth-O-Rama 示例的 Apple 工程师的话："[…] However, there's no way to close this race because of the weak concurrency guarantee for kauth_unlisten_scope."。如果有的话，请为它归档雷达。