Mac PrjFSLib: Use IOSharedDataQueue workaround library if available #429
Conversation
|
Previous discussion is at #161. For now this only deals with the userspace regression, which is vastly more severe than the kernel-side one. I can only rarely (< 1 in 10 million calls) trigger the kernel-side one very occasionally in synthetic tests that try to cause, so assuming it's fixed in 10.14.1, it's probably not worth spending much effort on. |
pmj
force-pushed
the
ioshareddataqueue-workaround-dylib
branch
from
a997ebd to
d5a36b7
Compare
| { | ||
| utsname unameInfo = {}; | ||
| if (0 != uname(&unameInfo)) | ||
| { |
There was a problem hiding this comment.
I'm unfortunately not aware of a nicer way to get the macOS version with just the C system libraries. (as opposed to Objective-C/Cocoa) There's also a "kern.osrelease" sysctl, but that returns the exact same version string as uname() that still needs to be parsed. Alternative suggestions welcome.
There was a problem hiding this comment.
Did you consider sw_vers -productVersion? That should give you the macOS version number, not Darwin. You'd still have to do some parsing though.
There was a problem hiding this comment.
That would require shelling out or reading the file /System/Library/CoreServices/SystemVersion.plist and subsequently parsing the string anyway as you say. I think a simple syscall is preferable in that regard. The Darwin version tends to change on very minor revisions (security updates, supplemental updates, etc.) too, so in theory that would allow us to turn off the workaround if Apple changed their mind and supplied a fix with a supplementary update to 10.13.6. (For example, I think there was a supplemental update to 10.13.3, which would explain why 10.13.6 is Darwin 17.7, not 17.6.)
|
Thanks @pmj for putting this together. We're having some packaging issues at the moment, but once that's done, I'll get your repo packaged up and set up a PR to consume it. Do you want this PR to go in first? |
I wouldn't mind getting this into the tree now, as it's one fewer local patch I need to keep maintaining - and the workaround is pretty much essential for preventing the log from seizing up during development/testing, so it should be useful not just for me. Until the dylib is packaged, we can just build it manually and place it in the same directory as prjfs-log. |
This allows PrjFSLib and the prjfs-log tool to use alternate versions of the IODataQueueDequeue() and IODataQueuePeek() functions from a dylib on OS versions where the built-in functions are buggy. On affected versions, a library "libSharedDataQueue.dylib" is loaded if available, and its implementations of the aforementioned functions are used for the message and kext logging queues instead of the ones supplied by the OS's IOKit.framework.
pmj
force-pushed
the
ioshareddataqueue-workaround-dylib
branch
from
d5a36b7 to
c7e221b
Compare
This allows the Mac PrjFSLib native library and prjfs-log tool to use fixed versions of the
IODataQueueDequeue()andIODataQueuePeek()functions which suffer from severe regressions in macOS 10.13.6 and 10.14. (Darwin 17.7.0 and 18.0)Assuming you have a dynamic library containing alternate versions of the aforementioned functions and place it in the library search path as "libSharedDataQueue.dylib", this change will cause PrjFSLib and prjfs-log load that library and use the versions of the aforementioned functions it provides instead of the OS's IOKit.framework's.