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.

After commandeering the revision, updating it to make sure my diff is the same as the previously submitted diff.

Adding @adrian and @rpaulo as reviewers, as they have been in this code before and might have input.

After commandeering the revision, updating it to make sure my diff is
the same as the previously submitted diff.

I'll take over this diff and get it committed to -CURRENT in the next few days.

Thanks. I'll take over this diff and get it committed to -CURRENT in the next few days. On what branch or revision did you test this? Do you need it applied to the stable/11 or stable/12?

@james.wright_jigsawdezign.com, do you need someone to help get this committed? I could do that if so. Can you update the review with information on testing you've done?

@james.wright_jigsawdezign.com, do you need someone to help get this committed? I could do that if so. Can you update the review with information on testing you've done?

This fix was (accidentally) committed in rS337812 and incorporated into the upcoming 12.0-RELEASE; I just noticed that now when I went to MFC that commit to stable/11. Closing the review now, considerably after the fact.

@vangyzen, Looks OK to me but I'm curious how you ran across this situation.

@vangyzen -- Did you notice this:

Looks good.

I would also agree with issuing a warning, masking the offending permission bits, and continuing.

This change has been merged upstream (netmap PR #520).

Looks good to me.

Fix style issue pointed out by @kib.

This review has been languishing for a bit.

Updating to rebase off latest head revision (rS336219). No functional
change from previous diff.

Fixed by rS335765