Note: I think TUR quirk is bogus, but don't have the courage to remove it.

markj reports the apple one was added because the autoprobe code screwed up his ipad with rockbox firmware.
he'll test this series to see if that's fixed, but it failed due to all the sync cache at the start in that code, as outlined in the disabling message.

In D49391#1128151, @dougm wrote:

In D49391#1128121, @markj wrote:

In D49391#1127942, @dougm wrote:

In D49391#1127890, @markj wrote:

The functional portion of the change seems fine, but I'm not sure why it's a problem for vm_page_grab* to support VM_ALLOC_WAITFAIL?

Because in comments on D49371, @kib suggested that VM_ALLOC_WAITFAIL was invalid here. So, to remove that obstacle to getting D49371 approved, I investigated and found that he might be right. Now, @alc has verbally placed a hold on this change because, when he is freed from another task, he plans to look for other illegal allocflag settings.

My reading of the comments is that kib is pointing out a bug in the new code.

He wrote, at D49371:
I am not sure about the semantic of VM_ALLOC_WAITFAIL. If we sleep inside vm_page_grab_lookup(), should we also return NULL for VM_ALLOC_WAITFAIL? (This is the pre-existing bug, if indeed a bug).

So I disagree that he is calling out a bug in new code.

In D49391#1128121, @markj wrote:

In D49391#1127942, @dougm wrote:

In D49391#1127890, @markj wrote:

The functional portion of the change seems fine, but I'm not sure why it's a problem for vm_page_grab* to support VM_ALLOC_WAITFAIL?

Because in comments on D49371, @kib suggested that VM_ALLOC_WAITFAIL was invalid here. So, to remove that obstacle to getting D49371 approved, I investigated and found that he might be right. Now, @alc has verbally placed a hold on this change because, when he is freed from another task, he plans to look for other illegal allocflag settings.

My reading of the comments is that kib is pointing out a bug in the new code.

In D49463#1128023, @markj wrote:

Whoa, nice. :)

What happens if tests are running in parallel? The behaviour I would naively expect is that other running tests will keep going, but new ones will not be scheduled until kyua is resumed.

Report test work dir

In D49415#1128114, @markj wrote:

Doesn't this leave msucc uninitialized in vm_reserv_from_object()'s callers?

Only if the function returns a non-NULL value.

If there are no objections, I will commit this soon.

In D49391#1127942, @dougm wrote:

In D49391#1127890, @markj wrote:

The functional portion of the change seems fine, but I'm not sure why it's a problem for vm_page_grab* to support VM_ALLOC_WAITFAIL?

Because in comments on D49371, @kib suggested that VM_ALLOC_WAITFAIL was invalid here. So, to remove that obstacle to getting D49371 approved, I investigated and found that he might be right. Now, @alc has verbally placed a hold on this change because, when he is freed from another task, he plans to look for other illegal allocflag settings.

IMO it would be nice to add a test case to tests/sys/kern/ptrace_test.c for this.

Doesn't this leave msucc uninitialized in vm_reserv_from_object()'s callers? I think we can then reach a msucc != NULL test there even if vm_reserv_from_object() returns a non-NULL pointer.

What happens if tests are running in parallel? The behaviour I would naively expect is that other running tests will keep going, but new ones will not be scheduled until kyua is resumed.

Fix a pre-existing typo in the manual's synopsis (s/x/w/).

update from rebase

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285385

Apply @markj comments.

Thank you for working on this! Can we add tests here?

In D49391#1127890, @markj wrote:

The functional portion of the change seems fine, but I'm not sure why it's a problem for vm_page_grab* to support VM_ALLOC_WAITFAIL?

In D49440#1127936, @mjg wrote:

can you instead sort the files and require the ordering that smaller is addr is locked first? a dedicated routine could do it

this would also avoid failures to lock to begin with

can you instead sort the files and require the ordering that smaller is addr is locked first? a dedicated routine could do it

Looks fine to me.

Looks fine to me, rick