Move vm_check_pg_zero code from vm_map_insert() into vm_object_coalesce().

Would you add a link to the actual defect page? Is it public?

In the checker, check that the pager does not contain pages.

In D53891#1231852, @markj wrote:

In D53891#1231400, @kib wrote:

In D53891#1231399, @alc wrote:

Can you elaborate on what you saw when debugging this problem? In particular, whether the map entries had OBJ_ONEMAPPING set? In principle, the ref_count and size shouldn't be a concern if the object has OBJ_ONEMAPPING set. For example, suppose there is an anonymous mapping (with OBJ_ONEMAPPING set) for the range [A, D). Further, suppose we punch a hole in the middle of that mapping, by calling munmap() on the range [B, C) where A < B < C < D. Now, we have two mappings, [A, B) and [C, D), that both reference the original object, and that object should still have OBJ_ONEMAPPING set. Because OBJ_ONEMAPPING is set, the munmap() should have freed any physical pages and swap space from the object that fell within the range [B, C). So, if a new anonymous mapping is created starting at either B or D, we should be able to safely coalesce it.

I did not have access to the object state there (all debugging was done remotely).

The situation you described is one of the cases that concerned me. I am not sure that we have a guarantee that doing the coalesce on the object with OBJ_ONEMAPPING flag but ref_count > 1 would not corrupt some other mapping. We need to do vm_object_page_remove(), and in principle that could remove pages which belong to other fragment.

I believe OBJ_ONEMAPPING means, "each page in the object is mapped at most once", so in the case you describe, OBJ_ONEMAPPING should not be set to begin with.

The rest of the changes.

In D53845#1231594, @imp wrote:

update per review...
... hope to get feedback on whether I should mention attach/detach here or not.

https://reviews.freebsd.org/D53896

In D53891#1231437, @mmel wrote:

After another day of extensive testing, I can confirm that everything is working properly.

I'm happy to perform additional debugging to clarify the problematic condition, should you find it helpful.
Would you like a dump of the affected object for the newly added goto remove_pager case? Or anything else?

In D53891#1231399, @alc wrote:

Can you elaborate on what you saw when debugging this problem? In particular, whether the map entries had OBJ_ONEMAPPING set? In principle, the ref_count and size shouldn't be a concern if the object has OBJ_ONEMAPPING set. For example, suppose there is an anonymous mapping (with OBJ_ONEMAPPING set) for the range [A, D). Further, suppose we punch a hole in the middle of that mapping, by calling munmap() on the range [B, C) where A < B < C < D. Now, we have two mappings, [A, B) and [C, D), that both reference the original object, and that object should still have OBJ_ONEMAPPING set. Because OBJ_ONEMAPPING is set, the munmap() should have freed any physical pages and swap space from the object that fell within the range [B, C). So, if a new anonymous mapping is created starting at either B or D, we should be able to safely coalesce it.

Drop KASSERT() checking the layout in vm_object_coalesce(). It really outlived its usefulness.

Move control var and sysctl under INVARIANTS.

Move to INVARIANTS and sysctl debug.vm_check_pg_zero to control.

Since there were no more active discussion, and there was some argument against removal of the compat code, I decided to go with the initial patch that just moved the powerpc rtld code into MD location. If there appear some consensus about removing AT_OLD_* for powerpc, the trivial patches can be re-created.

And where is __intcap_t defined? Is it provided by some MD include, like machine/_types.h?

There should be a description of the intended type use somewhere, even if only as a comment in the header. It is non-standard, and its proper usage should be documented instead of being a knowledge.

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

In D53801#1229366, @brooks wrote:

In D53801#1229342, @kib wrote:

After thinking about this code some more, I realized that it probably should be removed altogether. Basically, it is there to allow to run newer binaries (rtld/libsys) on older (pre-AT_ renumbering) kernels. This was done in ~2019, and arguably outlived even the limited usefulness it had at the time of the commit.

I'm not sure this analysis is entirely correct. __elfN(powerpc_copyout_auxargs) will use the old numbering if the binary is old (but not so old it doesn't have an OSREL embedded). What I'm not sure about is if this will happen with a new rtld and old binary or just with an old static binary.

In D53801#1229337, @tpearson_raptorengineering.com wrote:

On second read through, caught a couple of code issues that don't affect functionality. Once those are fixed this looks good.

Stub all arches

Remove the sentence.

pauamma' fixes

In D53736#1227776, @christos wrote:

In D53736#1227774, @kib wrote:

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

This is not what I am asking about. Why do you need to save the pid, and how do you use it?

Both the pid and process name are mostly cosmetic, and are used in sndctl(8), /dev/sndstat and in some OSSv4 structures. It is just so that the user can easily tell which channel(s) belong to which processes.

In D53666#1226868, @christos wrote:

In D53666#1226867, @kib wrote:

In D53666#1226866, @christos wrote:

2. Calling close(2) on the device: I'm not sure about this one. Is it possible that close(2) and read(2)/write(2) can run concurrently?

Yes, close(2) and io syscalls can be run in parallel. But the file is only closed (as in d_close for devfs, or cdevpriv destroy) when the file ref count goes to zero. Since both read(2) and close(2) take the reference, effectively the file deallocation occurs by the syscall that fdrop() it the last.

Right, so dsp_close() can de-allocate the channel (and as a result, the buffer) if it's a virtual channel (see vchan_destroy()). Would this be a problem here? If yes, I suppose we could an an inprog barrier in dsp_close() as well?

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

What is channel->pid? Where is it got assigned?

What would happen if a catch-able signal was delivered right before we entered select? Would the read built-in become blocked until timeout occurred then? [If yes, this is pre-existing issue in the code, I am only curious there]

pauamma corrections

emaste suggestions.
Removed 'would' for 'identifies'

Strip the license text