Looking at this more it was clearly a bug to have it RW to begin with, fixed here: https://cgit.FreeBSD.org/src/commit/?id=33fdf1afaea931eaa5dd14e6c097d7ffafe2fb1a

handling of this sysctl is already broken, it needs to be combined with cache_changesize

Given the above I'm closing this.

What is supposed to happen when this is a multithreaded program and multiple threads call quick_exit at the same time? While it is silly for such a setup to exist, I had the misfortune of encountering it (albeit with full-blown exit(3)).

what is stopping having the same fallback as locked lookup?

is this the only occurence of this "error" in the tree?

this would mean lookups of any absolute symlinks for linux emul would be guaranteed to start from scratch, wasting a lot of work

I found the bug around hte next day after introducing it, it must have slipped through the cracks afterwards.

same comment as for snmp

i don't think there is anyone to review this, just commit

I'm all for reducing tech debt and complexity in the area.

I only have cosmetics remarks vs the code, which I'm going to spare this time

it's all fine with me

tests can be moved to a different review which will land at a different date if that helps

I thought kib had possibly unresolved concerns.

I have no further comments

ok, fair. in that case i have no opinion about the posted patch and will defer to other people

but this is only trying to paper over part of the problem and flush_autofs still does not work?

So the fsid thing has a problem of being tied to NFS from security standpoint and is not even exported for unprivileged users.

there are weird whitespace issues, past that lgtm from asm standpoint

The mount update path should grow support for FSID, which would close the problem.

In D41337#941562, @dchagin wrote:

In D41337#941279, @mjg wrote:

my bad, the entire point was for validation to happen prior any automagic assignment so filesystems are forced to explicitly state their position on fplookup for given vop vector

I disagree, it’s not an automagic, it is a long lived well known stable code, and, of course, the fix doesn't change the purpose you wanted

So I went ahead and whacked this, see https://cgit.FreeBSD.org/src/commit/?id=b8b33f3b3b71ad7b4b5714afec21d6e8ad7fd6ce

In D41207#938592, @stevek wrote:

In D41207#938522, @kib wrote:

In D41207#938511, @mjg wrote:

is this really of practical usage today? i was considering removing these printfs to begin with

I agree, better to remove it.

I'm fine with removing it. We had someone use it recently and I did the change to make it easier to set.
Although I'm not sure how much use it would be, since I would expect it to be rather spammy.

But I think they were having a panic occurring in VFS code and, for some reason, they were not getting into the kernel debugger, even though it was supposed to be enabled. Therefore, they wanted to be able to tell what was being looked up. (Because of the panic, they could not use dtrace, as I would usually suggest.)

I can do the pruning, if you'd like and update this review to instead prune it out.

i was fine with strlen.S as the file was mine. stpcpy.S is not, I don't have a single line of code there. You should probably ask @emaste how to handle this. I *suspect* some form of "portions of this file blah blah" would do it.

i'm not going to argue over this