In D40403#920222, @markj wrote:

In D40403#920211, @kib wrote:

Suppose that a kernel dump happens very early, before pages are initialized. Then, e.g. kernel memory needs the backing pages to be functional for some variations of busdma to work. I know that at very least DMAR busdma requires it.

"kernel dump" meaning minidump? I think it is not a problem, since the minidump code always excludes free pages (they are not set in the vm_page_dump bitset), and non-free pages are always initialized.

Suppose that a kernel dump happens very early, before pages are initialized. Then, e.g. kernel memory needs the backing pages to be functional for some variations of busdma to work. I know that at very least DMAR busdma requires it.

Look at libexec/rtld-eld/rtld-libc/Makefile.inc

Consider e.g. kmem_bootstrap_free(). Isn't the code there depends on the vm_page structures being already initialized?

Hm wouldn't it better to fix the issue instead?
Is it enough to build rtld with the right compiler options?

Fix the order in before_io()

In D40281#919091, @des wrote:

This is a massively over-engineered solution to a problem that doesn't need solving. I'm not sure why you're pursuing this. The problem I set out to solve has been solved and the remaining race is insignificant.

Only add the macro where needed.

Do not block SIGINT, use flags instead. This slightly resembles Peterson lock.

I think I realized how this might be fixed more elegant, without compromising even the EINTR on stderr behavior. Instead of sys-blocking the signal, I can do it by exchanging two flags between the handler and fences. Updated patch follows.

In D40281#918781, @andrew_tao173.riddles.org.uk wrote:

In D40281#918468, @kib wrote:

How the effects of that are different than the current code, where the ^C handler just set a flag and returns?

The one difference of any significance would be if the program is blocked on writing a progress output to stderr (e.g. if that has been directed to a pipe) when you ^C it; a handler installed without SA_RESTART that just sets a flag could nevertheless cause an EINTR from the write, whereas with signals blocked the program will remain blocked.

I don't know if anyone cares about this.

I think it would be cleaner to have macro like PHYS_SZ_IN_DMAP(pa, sz) which would check for [pa, pa+sz) belonging to the DMAPed region.

In D38459#918467, @imp wrote:

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

So having a few extra system calls means they will be annotated and my job of getting it to work in bsd-user and others wanting to do automatic translation is easier.

In D40281#918424, @des wrote:

You are now blocking SIGINT whenever dd is not performing primary I/O. I don't think that's right.

How the effects of that are different than the current code, where the ^C handler just set a flag and returns? If my code is not right there, then the current unmodified code is not right either. I believe the correctness relies on the fact that dd performs a cpu-bound processing between i/o syscalls.

In D40318#917991, @markj wrote:

In D40318#917981, @kib wrote:

__acl_delete_file(2) is not permitted in capability mode, so there is some difference. A sandboxed program might reasonably expect that an O_PATH fd cannot be used to modify the underlying file (though CAP_ACL_* rights exist for this as well).

I do not see why would a cap-mode process be disallowed from modifying/deleting ACLs if it was granted rights by an O_PATH descriptor.

I think it is preferable to try and maintain some consistency with respect to other file metadata syscalls, like the fstat/fchmod example I pointed out.

Might be fchmod/fchown should work on O_PATH too, I am not sure.

In D40318#917975, @markj wrote:

The change makes sense to me for get and perhaps aclcheck operations, but it seems quite surprising to permit ACL modifications using O_PATH descriptors. For instance, fstat(pathfd) can be used to find the mode, but fchmod(pathfd) is forbidden. Does samba really require this?

In D40300#917875, @ae wrote:

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

IMO switching to print the stat unconditionally instead of doing it on SIGINFO is preferable then.

Is this really worth the complication with version check?

There are no XMM regs on aarch64.

Handle bz' comments.

In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

Bug fixes.

• Check for P2_WEXITED when deciding to skip the specific pid. Since P2_REAPKILLED is not set for such process, we might deadlock.

Several fixes for unr iterator implementation.

• Do not use % to calculate the clipped bit index in the current bitmap, simply substract the upos_first_item idx.
• Initialize upos_first_item for the first iteration where there is no compacted run at the beginning.