In D48700#1110954, @andrew wrote:

How difficult would it be to write a test for this?

In D48454#1110556, @yuri wrote:

This should be MFCed into 14.

In D48494#1106867, @zlei wrote:

In D48494#1106769, @kib wrote:

Since eventhandlers are called outside the vxlan_sx protection, it is not even guaranteed that the stop event comes after the start, or that events are properly interleaved. In other words, drivers must be prepared for the situation like 'stop without start' or 'two stops after one start'.

Emm, I read the code carefully, both vxlan_start and vxlan_event handlers are called within protection of vxlan_sx. So drivers will get proper event order. Am I missing something important ?

In D48509#1106934, @imp wrote:

Generally, I tend to like the changes. The extra indent forcing extra wrapping on things that are still somewhat simple suggests at least an experiment with 90 or 100 (or 110?) character lines for comparison might be in order.

obj_remap_relro() re-formatting

In D48509#1106853, @emaste wrote:

Overall I think this is a fine idea. I am curious about the manual fixups you applied (or put another way, how significant a subsequent clang-format would be). I tried running it again over rtld.c and see a bunch of things like

        for (ph = obj->phdr;
-           (const char *)ph < (const char *)obj->phdr + obj->phsize; ph++) {
+            (const char *)ph < (const char *)obj->phdr + obj->phsize; ph++) {

i.e., mine added an extra space to line up under the first char inside for's (). This feels like a clang-format bug to me.

Do you see such cases in the posted patch? I was not able to find it. I changed the ugly-formatted obj_remap_relro() control, and then also de-intended the body (in separate commit).
Note that I used llvm19 clang-format.

I am happy with any feedback.
The git-blame-ignore-revs file cannot be updated before commit.

Since eventhandlers are called outside the vxlan_sx protection, it is not even guaranteed that the stop event comes after the start, or that events are properly interleaved. In other words, drivers must be prepared for the situation like 'stop without start' or 'two stops after one start'.

I think that the commit must be split into much more fine-grained changes.

Set va_filerev to VNOVAL in vattr_null().
I do not think that other initializations can be removed.

Zero st_filerev in vop_stat_helper_pre().
Zero va_filerev before calling VOP_GETATTR() in vfs_stdstat()

In D48454#1105479, @olce wrote:

Switching to __thr_calloc() in _thr_alloc() basically means that the rtld allocator will always be used to allocate thread structures. Could that become a problem (perf, memory fragmentation, etc.)?

So far it was not a problem for mutexes. I am not even sure how to measure what you are asking, because threads are cached.

Zero st_filerev in tmpfs_stat()

I see that msdosfs did not update de_modrev, If I fix msdosfs and tmpfs to update vs_filerev, do we still need the flag? Or is it better to keep tmpfs/msdosfs as is and go ahead with the flag?

And where is the use of the new flag?
Also, what writable and exportable filesystems do not increment va_filerev on changes? I looked and only seems to find smbfs and tmpfs. It might be simpler to fix tmpfs than adding a flag.

As I understand, the patch causes the inactive scan to stop even if there is still page_shortage (>0), hoping that laundry would keep up and do the necessary cleaning. Suppose that we have the mix of the anon and file dirty pages, and, for instance, no swap (or files are backed by slow device). Then it is possible that for the long time, despite queuing the pages for laundry, they cannot be cleaned, so the page_shortage is not going to go away.
Wouldn't it be needed for such patch to ensure that either launder thread make progress, or inactive scan continues? I understand that scan would be kicked again, but I mean that laundry should kick it as well if it cannot get rid of page_shortage.

In D48373#1104032, @jhb wrote:

@kib btw while documenting this, I do wonder if we shouldn't just merge bus_print_child_domain into bus_print_child_footer?