Let's try uploading that diff again...

Modify the test to handle the nvme drives not starting at 0. I don't
think that is likely, but it is easy enough to handle.

Fix a problem in the devlist test when /dev/nvme0 does _not_ exist.

Remove the shared library unloading code at imp@'s suggestion.

Address comment about check on fd > -1 not being needed in passthru.c.

Correct diff; the previous one had some unintended files included.

Fix a couple issues pointed out in review comments.

In D24117#530232, @vangyzen wrote:

Wow, that API is unfortunate.

Made requested man page changes.

Updated to account for another syscall that was recently added.

Updated to account for another syscall that was recently added.

Someone snuck in another syscall. I'll update and commit this.

Looks good, Matthew; just a couple nits. It would be nice if you could upload a full-context diff with any further changes. When you think it is ready, I'll be happy to carry this through to commit.

Minor whitespace cleanup.

Reverted the change and am re-committing without these changes:

Yes, I did change the logic. This turned out to be a more interesting issue than I had initially thought. At $WORK we also have bug fix in this area, but it differs from mine. I'm working on getting a good review, reconciling the changes, and adequate testing. So, this shouldn't be thought of as a finished work (yet).

I can test on hardware at $WORK. As to it being vendor code, although the driver was imported from PMC-Sierra 3 years ago, it doesn't look to me like any updates have come from them since. If you know of a source of updated vendor code, can you point me to it?

Remove stray file from this review.

Fixed by rS343906

Taking @cem's suggestion for an alternative fix. While I was at it, I
expanded the scope to pick up some fixes for additional CIDs:

In D19109#408725, @cem wrote:

In D19109#408718, @mav wrote:

I think I would remove this code completely, together with above NULL assignments. One way or another, this check is at least incomplete, since just in if block before execution can go to out bypassing this check.

Hm, I guess the assertion could be moved above the if block. I am also ok with removing it completely.

In D19105#408658, @cem wrote:

My guess is that the author intended for defconf input to parse_file() to be a *reference* rather than a bare pointer. If you look at parse_file(), you can see it initializes its copy of defconf_p when the special entry "<default>" is encountered in a file. However, that pointer is never stored anywhere and is leaked when parse_file() returns.

Take @cem's suggestion to use a KASSERT() to ensure that lp is indeed NULL on the affected code path.