DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60MEpD0G2148628
Date: Thu, 22 Jan 2026 15:50:22 +0100
To: cygwin@cygwin.com
Subject: Re: Fork bomb question about Cygwin
Message-ID: <aXI5LisBF92YQAXy@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <MN2PR09MB492382DA1F993B72742E1A98A596A@MN2PR09MB4923.namprd09.prod.outlook.com>
 <aXH2YPIcgWqd8zyX@calimero.vinschen.de>
 <aXI3osLanp-VA5qV@calimero.vinschen.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <aXI3osLanp-VA5qV@calimero.vinschen.de>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Jan 22 15:43, Corinna Vinschen via Cygwin wrote:
> Unfortunately there's a tricky difference between POSIX soft limits and
> the way Windows job limits work.
> 
> - Soft rlimits can be changed by any process, up or down, as long as the
>   new limit doesn't exceed the hard limit.  A child process inherits the
>   limits, but it can change (raise!) them right away, only limited by
>   the hard limit.
> 
> - Job limits on Windows can be changed by the process, but the limits
>   are accumulated if jobs are nested.  The lowest limit wins.
> 
>   If a child process inherited a job limit, it can't raise the limit,
>   unless it knows the name of the job object *and* has the right to set
>   limits on this object.  The problem here is, the current job the
>   process is running in, does not necessarily contain the information
>   about the real limit.  This information may be in a job object higher
>   up in the job hirarchy.  Unfortunately QueryInformationJobObject only
>   returns limits defined in this very job, not limits defined higher up.
>   And there's no way to fetch info about parent job objects, unless you
>   know their names or still have open handles on them.
> 
> All in all, that means, the current implementation of
> setrlimit(RLIMIT_AS) is not quite correct.  The job object is inherited
> by children, but then, if the child defines a new limit, it just creates
> a nested job with this limit inside the already existing job.  So the new
> limit is ignored if the parent (or grandparent, or ...) job defines a
> lower limit.
> 
> Unfortunately the child can't just breakaway from a job.  Only the parent
> can do this for a child at CreateProcess() time.  So we can't just
> breakaway at setrlimit time and create a new, independent job object.
> 
> The bottom line is, if we want to do this right, we have to redesign
> the entire setrlimit thingy:
> 
> - always allow BREAKAWAY_FROM_JOB
> - always start the child with BREAKAWAY_FROM_JOB
> - always create a new job object in the child after fork/exec implementing
>   the soft limits inherited from the parent
> - in setrlimit: always just change the current job object

But then again, if we do it like this, per-process limits work as
desired, but limits like RLIMIT_NPROC would not work.

Did I say something about a tricky difference...?


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple