rebasing with minor additional changes before I begin the work to split this up

Interim PR changes while I work on splitting this up to different sub PRs. Don't want my work lost

I think the cycle detection patch is fine and should be committed on its own. If you send me (markj@freebsd.org) a patch with that piece of the change, I'll commit it.

Possible to get some eyes on this and see if we can get this across?

With many apologies for the delay, this is now sent.

In D46472#1061633, @sobomax wrote:

Undo damage done in c6d3d601c96f, which shifted failure to allocate large buffer to pipe_create() from pipe_write().

The need for such allocation by itself is questionable since absolute majority of users write less than dozen bytes and out of that majority most write exactly 0.

In D46472#1062498, @kib wrote:

This undoes the fix done in c6d3d601c96f5836df76847, which hurts real users.

Whatever band-aids you would try to put on top of the issue, it cannot solve the fundamental inability of computers to allocate infinite amount of resources. Perhaps, the only clean way to isolate one user from mal-acting neighbor is to implement per-uid pipe limit (RLIMIT_PIPEN), which is not that useless IMO.

This undoes the fix done in c6d3d601c96f5836df76847, which hurts real users.

In D45056#1061365, @allanjude wrote:

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

David, did you still need more help here?

Undo damage done in c6d3d601c96f, which shifted failure to allocate large buffer to pipe_create() from pipe_write().

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

Make harmless.

P.S. I think this whole new "behaviour" is the (unintended?) consequence of the c6d3d601c, which shifted the failure to allocate buffer from the write() call into the popen() call. Which added the whole new failure mode into fork()->exec() mechanism that can be easily triggered by anybody. So no new process can be created even if the new process and/or its parent would never want to write or read to the pipe in a normal conditions.

@kib thanks for the input. Beefed up telemetry, as suggested, removed the reference to tuning. Added option to kill the repeated offender (or an innocent bystander ;-)

Added option to kill Pipe KVA (ab)users.

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

Updated with last PR fixes

This broadly looks good to me. I verified that the existing ggate regression tests pass with this change.

Rebase and remove unnecessary () in an if check (per review comment)

Previous version did have one compile error (missing ;) in the file I warned I had not tested; also updated usage to match man pages

Any update on getting this committed? Might this make it in for 15-release?

Updated diff -U99999

Updated with PR comments

Updated for -U99999 as requested.

Can you please regenerate a full patch using -U99999?