Hello developers and developer-adjacents!

With the impending integration of illumos#13915, the private-but-used-by-others 
installctx() call gains a 9th parameter, which is either NULL for old-behavior, 
or a non-NULL result of the new installctx_preallocate() call for installctx() 
callers which are in a kpreempt_disable() block.  This constitutes a FLAG DAY 
for users of installctx(), and their outside-illumos-gate modules that call 
installctx() should be rebuilt on a kernel that has illumos#13915 in it.

Of general interest is that illumos-available HVM hypervisors like: bhyve, KVM, 
and VirtualBox use installctx(), and will have to take into account this 
change.  A pre-this-flag-day binary will have undefined behavior when run in a 
post-this-flag-day kernel.  I know at least OmniOS has changes ready for their 
build of VirtualBox, and I encourage other distros to do the same.

- If the installctx() call is inside a kpreempt_disable() section (like it is 
in illumos-kvm), the caller must use installctx_preallocate() in advance of 
kpreempt_disable(), and pass its result as the new 9th argument to 
installctx().  For example:

        struct ctxop *ctx;

        ...
        ctx = installctx_preallocate();
        ...
        kpreempt_disable();
        installctx(....., ctx);

- If the installctx() call is NOT in a kpreempt_disable() section, an additonal 
NULL must be added at the end of the parameter list for installctx().  An 
example diff:

-       installctx(...);
+       installctx(..., NULL);

Since installctx() is not a documented part of the DDI, we can make this change 
with only this warning.

Of note:  There is an ADDITIONAL change coming (illumos#13917) that refactors 
installctx() entirely to be more "ergonomic" as the filer accurately puts it. 
And that may too require another flag day.

I apologize for the need for a flag day, and appreciate your patience.  I 
encourage people to review illumos#13917, which will refine thread 
context-switch hooks even further, and lend itself well to potentially reducing 
memory allocations by encouraging reuse in some situations.

Thanks,
Dan


------------------------------------------
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/T38b7ddf6f14b64a6-Ma9440417fa226fb41ba45f58
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to