It looks like your most recent change rebased the base revision. That makes it very hard to see which changes are from you and which aren't. Could you please either un-rebase it or, if that's not possible, open a new review?

Using two completely separate functions reduces the scope of error. Also prevent any mutation to the current code path for not locked vnodes, while allowing it to work for locked vnodes.

• updated sys/kern/vfs_cache.c to reduce code duplication with vn_fullpath_dir
• some trivial changes

Regarding code duplication in vn_fullpath_dir_locked:
I modified vn_fullpath_dir(and removed vn_fullpath_dir_locked) for optionally locked vnode here in git commit: https://github.com/shivankgarg98/freebsd/commit/418c1c2a6de9989fe7a541f6111ee2c3f2786c7b
It works fine NFSv4=3 case but somehow breaks nfsrvd_open to result in an error.{and hence can't open/create a regular file from client}.
Using two completely separate functions reduces the scope of error. Also prevent any mutation to the current code path for not locked vnodes, while allowing it to work for locked vnodes.

follow-up on suggested changes.

This is a much better locking strategy. However, there's a lot of duplicated code. Could you maybe combine the _locked with the original functions, so there wouldn't be so much duplication?

removing unlocking/relocking implementation for vnode for auditing path, instead, define separate functions in vfs_cache.c for locked vnode as argument.

Thanks for all suggestions. I have incorporated them into my code. There is just a directory vnode unlocking/relocking issue not done yet.

In summary, locking and unlocking vnodes in this code is dangerous
and I am not in a position to make sure what you do is safe.

follow up on changes suggested by asomers@

Presuming all the testing works :-)

Minor comment - results of real-world testing of cracking resistance, both for the 11.x defaults and for those proposed by D15713.

All comments are minor.

Any chance of this being moved forward in time for the 12 branch?

I'm hopeful that this fixes style, and other suggestions from delphij.

Updates remaining man styles.

In fairness, this example pre-dates the crypt_r in FreeBSD by 4+ years.

This update covers the linting, and simplified example code in the libcrypt manpage.

Could you please split the proposed change to smaller pieces, so it would be easier to review?

There are a bunch of style issues with crypt.3. Can you run "mandoc -Tlint" and textproc/igor (from ports/packages) on it? It should give you some feedback where the problems are. For example, man pages need a line break after a sentence stop.

Fix loop always executing twice (in pw+pam_unix), with leaky memory.

Fix accent on David's name, per imp feedback.

Was already committed in r445228.

As been committed as rS294326 (discussed with des)

Apologies, I intended to Commandeer -> Close.

This is already in the tree (apparently no one approved it though).

Committed as r288669.

Results from exp-run (PR 2013394) are out:

Exp-run results on head i386:
http://package23.nyi.freebsd.org/jail.html?mastername=headi386PR203394-default

Peter Holm has kindly provided some testing:

In D3463#77043, @delphij wrote:

...

Will it be possible that you can provide some basic test data, for instance, a few world stone runs on memory disk, and see how exactly the impact would be? It would be easier to convince people when you have first hand data, and although we know others have already do some testing, it's important to know if the same applies on FreeBSD because it's likely that the experiments were not on FreeBSD, and the result may be different.

I'll patch my laptop and have started a clean build so I'll see if there would be visible performance/other impact after running with it for a few days.

+1

In D3463#70669, @imp wrote:

What's the performance impact?

We should investigate that the -fstack-protector-strong triggers the same as -fstack-protector-all:

What's the performance impact?