Re: ulimit -d/-m do not actually work

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 22 Oct 2024 17:56:38 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <vf8p0m$rue$1%serpens.de@localhost>

  | malloc doesn't use the "data segment", so that limit doesn't apply to it.

I'm not sure that's a reasonable argument.

As far as the resource limits go, there are 3 kinds of address space,
text (code and anything else unwriteable and sharable), data (almost
everything else, whether originally considered "data", "bss", "common",
or any other means of adding writable general address space), and the stack.
(And yes, the distinction between stack and data is somewhat nebulous).

At least for this purpose, and I suspect for any other, I doubt it matters
what mechanism is used to allocate address space for the application.
Everything should be counted in one of those three categories for resource
limit purposes.

When memory is allocated by mmap() it should be classed as text or data
depending whether it is write protected or not, and if that is changed
using mprotect() its status can change (subtract the amount from the usage
for one limit and add it to another).   If a mapping (or a protection
change) would cause the relevant limit to be exceeded, the mapping,
or protection change, should be rejected.

Why anyone would believe that memory allocated by mmap() should
be exempt from any of this I fail to understand.

That it currently happens to be I think is just a bug.

  | Things were much easier when these limits were invented,

They were indeed.

  | in particular without multithreading and shared libraries, a single heap
  | (the "data segment") was sufficient for all memory allocations.

How the allocated memory is used by the application is immaterial.
That doesn't (or shouldn't) matter for the decision of whether or not
the process (as a whole) has reached its limits.

It doesn't for others, the file descriptor limit applies to a process
regardless of which thread, shared library, or whatever else, is
attempting to allocate a new one - once the limit is reached, it is
reached.

Certainly the values of the limits are all much higher now than anyone
would have considered reasonable in the early 1980s, but that's also not
a consideration that matters (for this purpose).

kre