Increase the size of PIPSIZ from 8192 to 65536

[kbowling]

Summary

This is useful for i.e. KDE and browsers which behave bizarrely with small buffers. I can't think of any reason to limit these as they were.

[tcberner]

Awesome, this should also make databases/akonadi work out of the box, I think.

[markj]

Is the problem that these applications are trying to send large (>8KB) messages? Why not bump the dgram limits as well?

[kbowling]

In D16497#350684, @markj wrote:

Is the problem that these applications are trying to send large (>8KB) messages?

I think the problem is that for !SOCK_DGRAM, these are sockbuf sizes so it's fundamentally awkward to move larger IPC through such a small buffer. Your statement would make sense but I don't actually have any supporting evidence or traces and don't really care to gather it right now. Tangentially this is related to FreeBSD BZ 181741 you are working on with Firefox, i.e. we are generating the control messages in the first place because the limit is so low.

My desire to increase these is in response to the disappointment of the Mozilla devs i.e. in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1475970#c3

Why not bump the dgram limits as well?

Seems unrelated and I have even less context on potential pitfalls. The surrounding comments mention these are effectively dgram size limits for SOCK_DGRAM. On inet, they are 9216 so roughly 4x bigger send size and 2x bigger recv.. probably related to common jumbo MTU?

[kbowling]

xnu has the BSD limit (which appears to go back to 4k in UNIX v6) but Firefox appears to use Mach IPC on that platform https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/kern/uipc_usrreq.c#L789

[markj]

In D16497#350714, @kbowling wrote:

In D16497#350684, @markj wrote:

Is the problem that these applications are trying to send large (>8KB) messages?

Tangentially this is related to FreeBSD BZ 181741 you are working on with Firefox, i.e. we are generating the control messages in the first place because the limit is so low.

I don't follow... according to the report, firefox is sending a FD (i.e., a control message) together with >8KB of data. That's sufficient to trigger the bug in PR 181741. Raising the default socket buffer size to 64KB+epsilon would hide the bug again.

In D16497#350115, @tcberner wrote:

Awesome, this should also make databases/akonadi work out of the box, I think.

Is there a PR or any documentation of the problem you're referring to? Is it possible PR 181741 is also relevant there?

[tcberner]

For akonadi, we added a pkg-message.

There have been upstream bug reports, but for example this one being the most recent.

[markj]

In D16497#350901, @tcberner wrote:

For akonadi, we added a pkg-message.

There have been upstream bug reports, but for example this one being the most recent.

Thanks. Are you able to test the patch in D16515 with the default sizes are restored? I would like to understand whether a kernel bug is being triggered in this case as well.

[kbowling]

FWIW Firefox 61 with 7 content processes is 100% stable with this change whereas it was crashing several times per day before. I am happy to see you making progress on the root cause, but I can't think of any reason not to bump this up a bit either.

[kbowling]

@markj can you weigh in on whether this should land or not?

[markj]

In D16497#362772, @kbowling wrote:

@markj can you weigh in on whether this should land or not?

I don't see a good reason for it. PR 181741 apparently affected a lot of applications and it's not clear whether any of issues cited in this review persist now that the issue is fixed. If so, I would want to understand those issues before blindly raising socket buffer defaults, which was also a workaround for PR 181741. Applications which specifically require large socket buffers can and do modify the limits using setsockopt().