mirror of
https://github.com/reactos/reactos.git
synced 2024-11-23 11:33:31 +08:00
fe23a4aaeb
The PR #6649 which fixed an issue with orphaned KCBs leaking in memory which also pointed to unloaded registry hives, it also brought a problem. In CmpEnumerateOpenSubKeys there is a risk of getting hit by a deadlock as we enumerate the cache table to remove empty cache entries. Fundamentally CmpEnumerateOpenSubKeys locks down a KCB from cache for exclusive use in order to tear down its contents from memory but it doesn't address the fact a KCB might have already been locked in the same calling thread, leading to a recursion. This leads to random hangs when unloading a hive during system startup (tipically on a clean install). The solution here is to simply lock the whole registry when we unload a hive so that we don't have to worry the KCBs are getting tampered by anybody else. This also simplifies the code. Although locking the entire registry while other apps are doing registry related operations to other hives can cause overhead. If this turns out to be bad then we have to rethink the locking mechanism here. CORE-19539 |
||
|---|---|---|
| .. | ||
| arm | ||
| i386 | ||
| cmalloc.c | ||
| cmapi.c | ||
| cmboot.c | ||
| cmconfig.c | ||
| cmcontrl.c | ||
| cmdata.c | ||
| cmdelay.c | ||
| cmhook.c | ||
| cmhvlist.c | ||
| cminit.c | ||
| cmkcbncb.c | ||
| cmlazy.c | ||
| cmmapvw.c | ||
| cmnotify.c | ||
| cmparse.c | ||
| cmquota.c | ||
| cmse.c | ||
| cmsecach.c | ||
| cmsysini.c | ||
| cmvalche.c | ||
| cmwraprs.c | ||
| ntapi.c | ||