In D33199#750855, @markj wrote:

In D33199#750851, @asomers wrote:

But syslog(3) already handled that problem by splitting long messages up into multiple messages of no more than MAXLINE characters each. If I try to log a very long message, it still gets logged, but as multiple separate messages. That doesn't require increasing MAXLINE.

No, syslog(3) will truncate long messages. If you're using logger(1) to test, note that it handles splitting itself.

In D33199#750847, @dmitry.wagin_ya.ru wrote:

I fully understand what Alan wrote. But the SO_SNDBUF setting is also needed. It doesn't matter what size the buffer is on reception (syslogd 80kb), if you send messages larger than SO_SNDBUF (by default from net.local.dgram.maxdgram) nothing will work.

In D33199#750243, @markj wrote:

Ok with me since it fixes a regression. I do wonder if it's finally time to up the default socket buffer sizes though. I'm a little surprised that rsyslog uses the default.

Thanks for your input, @rmacklem . You're probably the most knowledgeable person about VOP_COPY_FILE_RANGE in general. @pfg , do the fuse changes look good to you?

This is a very awesome feature! A few questions:

In D33145#749045, @pfg wrote:

I will admit I don't like this. Does linux do the same?

What's up with these file names that end in .write and .stat ?

What about nfsrpc_readdirplus, nfs_mknodrpc, nfs_lookitup, and nfs_create? It looks like they're all vulnerable to the same race. Though in some of those it's only a directory vnode that could be affected, so there's no file size to worry about.

Sorry I didn't notice when you first put this review up. It looks good, except:

• Needs a Makefile entry
• Need to trim the trailing newline.

Do these utilities always run in verbose mode now?

• add test cases suggested by @emaste

In D32344#735039, @emaste wrote:

should we add a test for exit:1 with -46 specified?

It wasn't committed as-is, but all of the fusefs sysctls have since been described by separate commits.

This looks good, but I'm surprised that there aren't more transitive dependencies that can be removed. For example, zfsd doesn't use libzfs_core directly, only through libzfs. Can libzfs_core be removed from its LIBADD?

Sounds smart. The existing test suite should cover this.

I didn't realize that the revision title was set wrong at first. Phabricator can handle multi-commit diffs, but apparently it sets the title based on the first commit, and in this case that wasn't the most important.

• Changes suggested by @0mp

In D32141#725425, @pfg wrote:

Interesting ... I don't see the old protocol described upstream

BTW, gstat-rs already implements the interactive a and p keys, and it has other keys that provide the same functionality as d, o, and s. All it needs is approval from a ports committer. https://reviews.freebsd.org/D31359 .

@brd is there anything else this port needs?

Powerpc64 has a sig_atomic_t shorter than a pointer? ughh. Does that mean that it doesn't have any 64-bit atomic types?

@kib I rebased the changes.

• Delete unintended code
• Use setjmp/longjmp to handle SIGBUS instead of mlock
• Verify the address of the faulting data
• Use a memory fence after the faulting instruction
• Correct memory fence placement

• Correct memory fence placement

• Use a memory fence after the faulting instruction

• Verify the address of the faulting data

Yes, I think that makes more sense.

The change looks fine. But the commit message is incomplete, because it doesn't mention removing the panic in fuse. Should I merge this change into D31994 ?

• Use setjmp/longjmp to handle SIGBUS instead of mlock

Why are you changing the blksz from an int to a long? The commit message doesn't mention that.