In D33055#750313, @jrtc27 wrote:

In D33055#750301, @jhb wrote:

I generally trust @jrtc27 on this.

@brett_gutste.in Does the fix to ignore offsets for !ET_REL help with PIE binaries (e.g. does it reduce the scope of some of your patch over in CheriBSD to fix hwpmc on PIE?)

I believe it should fix everything for PIEs except the lack of knowledge about what the base load address was, since won't get a MAP_IN event for it like shared libraries?

Right, I'll drop that check.

Regarding the fallback solution, I believe it is okay to fall back on vmem_xalloc() regardless of whether vmem_alloc() is called with M_WAITOK or M_NOWAIT (i.e. the if statement on line 1299 is not necessary). If vmem_alloc() is called with M_NOWAIT, then the fallback vmem_xalloc() call will also have M_NOWAIT and could also allocate the range starting at 0.

As I understand it, there are now two qualitatively different vmem_xalloc() calls that could be made when a user calls vmem_alloc(). The first is the vmem_xalloc() call used in qc_import() to fill the quantum caches when needed, and the change to this call's parameters means that a quantum cache will never contain the range from 0 to QUANTUM_SIZE - 1. The second is called directly by vmem_alloc() if the allocation size exceeds those supported by the quantum caches, and this call could still allocate the range from 0 to QUANTUM_SIZE - 1.

I believe this change means that the range from 0 to QUANTUM_SIZE - 1 cannot be allocated by vmem_alloc() when quantum caching is enabled (except as part of an allocation request that is too large to be satisfied by a quantum cache). Should the qc_import comment state this explicitly?