This is fine... it does highlight a bit more the impedance mismatch between kernel build and stand alone builds as options bleed out of the kernel...

This seems a reasonable fix for the problem at hand... I don't object, but John may have a specific case in mind...

I think enough time has passed.

I think there be dragons here.

In D24938#549385, @cem wrote:

Kobj dispatch is on first method argument; correct method argument order to put
table first. In retrospect this is obvious but kobj doesn't detect this nicely
at either compile or runtime.

All this angst over reading a directory which you shouldn't be doing since around 1983 or so.
fsdb is adequate, or should be updated, for debugging these things. It uses an existing security grant. And if you're looking at the low-level stuff, you'll likely need more information that just the dirent that you can get from reading the directory.
But, you can't do any of that with zfs, nfs, or others.
I've almost never wanted to read directories to get the dirents from them, even while debugging. They are at best, mildly interesting.
Adding another security knob to allow this for a niche use-case seems like overkill. Meh. The patch is fine.

In D24596#547104, @mateusz_serveraptor.com wrote:

Probably grep(1) should be updated after this change. It has -d option to specify which action to to take on processing directories. From manpage:

-d ACTION, --directories=ACTION
       If an input file is a directory, use ACTION to process it.  By
       default, ACTION is read, which means that directories are read
       just as if they were ordinary files.  If ACTION is skip,
       directories are silently skipped.  If ACTION is recurse, grep
       reads all files under each directory, recursively; this is
       equivalent to the -r option.

In D24825#546329, @rpokala wrote:

What about NVMe and MMC? If they don't have this problem, please say so in the commit message.

In D24762#545728, @rpokala wrote:

I note this is now creating an alias in NVMECAM, as well as in the GEOM layer; why both?

Follow on work may include assuming c++11 or c++14, but this is a great start and should be committed as is, module units from the review.

I'd be tempted to loop in the security folks for a comment on sysctl vs tunable from a security perspective.

Thanks cem

Love it. Easy to upstream.

Or noisily complain / panic?

Can we hack clang to warn? Or enable a clang option?

Looks great.

Like the changes. Thanks for attending to all these pesky details.

While there's continuing improvements here from time to time, the bulk of this work is done.

Add comments that cperciva noticed on IRC.

Doh! I pushed the wrong branch :(. So I'll fix things in a followup. I *THINK* I got this mostly right since I didn't need to add any new 'reach over' pointers...

I like this idea.

Will need to remember to bump config version for anything that uses a driver that's tagged with this.

Other than what I think is a left over sys/elf.h include, this looks good.

In D24489#539551, @scottl wrote:

Blah, but thanks for the history on it, I guess I never noticed before. I would be surprised if this hasn't caused bugs. There's no longer an active standards group, and even if there was I'd advocate that this is wrong. Let's follow up with a change on it.

LGTM, but this stuff is tricky so you may want to wait for it to look good to others too.

Obtained From: NetBSD

Why the move from contrib?

In D24480#538892, @mav wrote:

I worry this is at least incomplete implementation or even wrong approach. The problem I see in what happen if/when the command still complete after the polling gave up, or when the timeout handler expire. I think at very least it will be a stack corruption.

Lgtn