Looks good to me.

My first thought about the high network priority was about serial ports without any hardware buffering and flow control, extremely sensitive to interrupt latency, but uart seems to use TTY priority, at least now. Not sure what else could be so time-critical in networking before, but sure there could be NICs with very few RX buffers. Typical disk hardware though should have much higher latency tolerance, since the amount of traffic is usually predetermined being initiated from the system, that is why I guess its priority was set lower.

I see in NETWORKING: "# PROVIDE: NETWORKING NETWORK", so it does not look broken to me, but it looks weird.

In D29222#654210, @imp wrote:

If we do the wakeup with the lock held, then that race isn't possible and the wakeup won't be missed.

As me and John just told, the wakeup will not be missed in any case, it can only be duplicated due to the race, since list inserting is done before that under the lock.

In D29222#654204, @imp wrote:

In D29222#654202, @mav wrote:

I am not getting what is the point of bringing the wakeup() under the lock. Being out of the lock may cause extra wakeups, but they are not critical here.

Doing the wakeup outside of the lock races the waker. If you do it inside of the lock, it won't race.

I am not getting what is the point of bringing the wakeup() under the lock. Being out of the lock may cause extra wakeups, but they are not critical here.

In D29101#652362, @chuck wrote:

So the recommendation for zpool is to use the first version of the patch that call root_hold_wait before the zpool import, correct?

Still LGTM.

For root on ZFS kernel automatically calls vfs_mountroot_wait() before doing anything. I think it is the only safe way. Attempt to import pool before all disks are detected may end up in importing pool at older transaction group or using old, removed now from pool devices. So I would insert root_hold_wait call at the beginning of zpool_start().

Should probably be merged with D29005.

I like the general direction. I also was thinking about something like this to avoid callout operations on every I/O.

I have no specific objections, but I suppose those were added for something.

Other than the commend above I think it may work.