In D50910#1162053, @emaste wrote:

The PR has a list -- usr.bin/bmake/unit-tests/Makefile has both MALLOC_CONF and MALLOC_OPTIONS set so it's fine, although inconsistent between the two.

Seems fine.

In D50648#1161495, @kib wrote:

The patch in the review is outdated, it got a lot of fixes. Peter is testing ATM, I will update the change after he is done.

I should be able to do some parallel buildworld tests this week.

Changes prompted by kib@ comments.

I've rephrased following your advices, mentioning potential exceptions only in the commit message.

I'd like the opportunity to review this (next week).

In D50648#1156311, @markj wrote:

Is it really worthwhile to try to improve scalability of renames? I suspect that in practice there are enough bottlenecks elsewhere that it's not important, e.g., if multiple processes are renaming files within the same directory during a build, they will already collide on vnode locks.

In D50371#1155992, @markj wrote:

With the patch, P2 should not be able to traverse out of the directory. But suppose P1 renames the subdirectory foo at the same time that P2 does a relative lookup like foo/../../. I believe it's possible for the lookup to succeed if the rename is done after the lookup of foo but before the lookup of foo/... Does something prevent this?

For some reason, I had missed the existence of um_checkpath_lock, which implies that some renames (involving directories whose parent directory changes) are basically serialized. Since this was added in 2021, probably nobody really complained, but that is slightly surprising to me.

Statistics for the web browsing simulations:

New round of multiple tests, to ensure the current anti-starvation and nice behaviors stay (approximately) the same after this series of patches.

In D50531#1153938, @markj wrote:

openatfp() ORs FOLLOW into the cnflags unless O_NOFOLLOW is set, and zfs_setextattr_dir() does not specify O_NOFOLLOW. So its use of NOFOLLOW is silently getting converted to FOLLOW. Maybe it's not a real problem in practice, but it doesn't matter that NOFOLLOW is 0.

Browsing some old notes, I had noticed that cn_flags were sometimes crushed, and concluded that VN_* flags probably were just workarounds for that problem, except for VN_OPEN_INVFS.

Much clearer with a bool indeed, and solves my concern.

Oops, sorry, I inadvertently committed this along with something else... Re-opening.

I have mixed feelings about this proposal. But let me first begin with some context about mac_do(4)/mdo(1).

Seems fine, except for one thing, please see inline comment.

Some now unused code could be suppressed.

Thanks!

Thanks.