• Use vnode_pager_clean_sync

In D43448#990336, @kib wrote:

In D43448#990317, @asomers wrote:

In D43448#990316, @kib wrote:

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

Why would you use lio_listio with nelem == 1 ?

Because you can specify op with modifiers. This is impossible with current syscalls like aio_read(2).

In D43448#990316, @kib wrote:

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

Will an operation with LIO_FOFFSET update the current file offset? What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

It LGTM, but let's get some outside review, too. @des what do you think?

In D43358#988308, @markj wrote:

Does this all happen sequentially, e.g., from a single thread? I'm a bit confused specifically by how we end up in putpages. Do you have a stack trace handy?

In D43358#988241, @markj wrote:

In the problematic scenario, we are writing pages starting at EOF. (How exactly does that happen?)

I don't grok this page cache stuff. But your patch works for me. BTW, fspacectl was a red herring. I can actually reproduce the panic with just a single mapwrite, as long as the size and offset are suitable.

This looks correct to me, but I haven't tested it in any way. I think it's a good candidate to add to pjdfstest.

This is the same as the 2nd patch you posted to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276002, right? That one does not fix the test case.

Oops. I accidentally included way too many commits. I'll close this review and start over.

@markj All tests pass on my admittedly somewhat trailing edge hardware.

In D43130#982962, @markj wrote:

In D43130#982959, @asomers wrote:

LGTM. Do you need help testing it? I can test it for you, if you lack appropriate hardware.

Yes please!

LGTM. Do you need help testing it? I can test it for you, if you lack appropriate hardware.

@oshogbo I've updated all of them now. But do you think that this is too pedantic? Maybe I'm just a cossetted Rust programmer who expects that everything is thread-safe by default.

• Add reentrancy notices to the other casper service man pages, too.

@oshogbo do you agree with this wording? If so I'll add it to the other casper services' man pages and update the revision.

In D42825#976834, @imp wrote:

I'd have liked to see these configurable thresholds for people that want to more or less aggressively fault things.
But as is, it's fine, and it's a nice to have not something absolutely required.

ping @jrtc27 does the latest version look better to you?

LGTM. But under what circumstances can mp be NULL? We should probably add a regression test for that.

• style fixup to "libc/libc/rpc: refactor some global variables"
• fixup to "rpc: Replace per-fd condvars with mutexes in clnt_{vc,dg}.c"

• style change to dg_fd_find and vc_fd_find
• rpc: Replace per-fd condvars with mutexes in clnt_{vc,dg}.c

• Respond to kib's comments.

This latest version fixes the script with UFS, and makes the bootconfig script less ZFS-specific.

• Add ESP to all ZFS boot disks, pretty edition