In D18670#426579, @crees wrote:

If the zfs.ko module is loaded, a zfs module exists in the kernel, but I suspect that zfs doesn't exist in a kernel with it compiled in; only zfsctrl, based on what avg has suggested

Once again, you are confusing a name of a loadable file with a name of a module. Which is not surprising as that duality is confusing. E.g., a single loadable file can contains multiple modules.
Whether ZFS is compiled into the kernel or loaded via zfs.ko, the module name is still zfsctrl. It's the module name.

In D19817#426388, @imp wrote:

This looks good to me, however I'd wait a few days to see if Scott can spot something that I can't.

remove a wrong panicstr check that was left by accident

In D19833#425585, @kib wrote:

In D19833#425441, @avg wrote:

LGTM.

I wonder if the pci_cfgregopen problem reported for AMD Ryzen systems has a similar cause...

What is the Ryzen problem ? This issue can only occur when config space is accessed before pmap is initialized, and I am only aware of pci_early_quirks which do that, which might falls to MCFG access only on some Intels.

I wonder if the pci_cfgregopen problem reported for AMD Ryzen systems has a similar cause...

• update

In D19094#417188, @slw_zxy.spb.ru wrote:

No more replays?

Thank you, Rick!

Somewhat belated question, would it make sense to mark the client created in sys_gssd_syscall() as interruptible?

I consider using the whole "Src committers" group as a reviewer to be inappropriate.
Especially for a change in a minor utility.

I haven't thoroughly examined the change, but the procedure you followed sounds good to me.
And if it works, then it is good enough for me.

In D19094#411932, @slw_zxy.spb.ru wrote:

Do you succesefull contact George?

Let me try to contact George again.

Not an expert on these matter, but I have no problem with the change.
Thanks!

Or if a "boot pool" setup is used (kernel is loaded from one pool, root is mounted from another). Or if reboot -r has been run prior to zfsbootcfg.

At work we decided to use the approach of if_gif / if_gre.
So, we don't really need this change.
But if people find it useful (e.g. @ae) and no one objects (looking at @bz), then I would like to commit this change and to merge if we have a spare field.

correct description of the new sysctl

While here, I also fixed setting of the next state in the case of malloc failure in DA_STATE_PROBE_WP.

Unfortunately, I disagree with this change. I think that it is backwards.
illumos has already translated their zfs.1m and zpool.1m to mdoc format, so I assume that that's the direction they are moving in.
I'd rather help them with that in this case as well.
IMO, that would be a better way to overcome the divergence.

• add and make use of rman_{get,set}_irq_cookie() and a new field r_irq_cookie to back them
• slide up head

In D18420#392363, @ae wrote:

I'm inclined to agree. For tunneling interfaces I used global per-driver sx lock to prevent concurrent ioctl invocation. I think these drivers are not affected by this problem.

In D18420#392349, @ae wrote:

Can you provide an example, what another driver needs such method? Maybe it is enough to fix the problem locally in if_lagg for first time?

In D18420#392053, @bz wrote:

Sorry but my understanding is that this could possibly free the softc even before lagg_clone_destroy() has finished, couldn't it?

Maybe rather than removing the code it would be better to ifdef it out?
But not sure. What are plans for illumos in this respect?

In D17465#386206, @selwinsebastian_gmail.com wrote:

Scheduler should be aware of the topology of socket also as to keep threads in same socket if possible while migration as

I see what the change does but not why. Could you please provide some rationale?

In D17585#375321, @mav wrote:

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.