shithub: devlimit-patch

branches: front


clone: git:// gits://
push: hjgit://
patches to:

Last commit

a9f94671 – kitzman <> authored on 2024/02/22 02:45
added patch and README


     LIMIT(3)                                                 LIMIT(3)

          limit - system limit interface

          bind #Λ /mnt/limit


          The #Λ device provides the interface to the system's limit
          mechanism.  Each process has a limit group assigned. Groups
          are created as children of other groups, are represented by
          an id, and follow the restrictions imposed by their parents.
          A group is deleted the moment there are no more processes or
          segments referring to it.  The group is owned by the uname
          and gid of the creator process, and the attributes can be
          changed. The system's group, with id 1, imposes no restric-
          tions and does not increase counters.

          The root directory contains the ctl, clone, switch, status
          files, and a directory named groups.  The current process'
          limit group is always presented in the root directory, and
          other groups, in the groups subdirectory, where they have
          the same files, except for the groups .

          The ctl file controls the limit group's attributes, namely,
          the label, and the limits.  Reading the file returns the
          limit group's id. The following commands are supported:

               label label    Set the group's label; the labels need
                              not be unique.

               mlim number    Set the maximum amount of groups that
                              can be created from this group.

               mproc number   Set the maximum amount of processes that
                              can be forked inside this group.

               mpage number   Set the maximum total amount of pages
                              that segments inside the limit group can

          Reading the status file shows the group's attributes: the
          label (or an empty line if not set), the parent's id, the
          current limit restrictions on the left, and the counts, on
          the right.

          To create a new group, the clone file should be opened.
          Reading from the fid returns the newly created group's id.
          This creates a new reference, and when the fid is clunked,
          the reference is destroyed. A reference is also created for
          the parent limit group.  Thus, the opener's process limit
          group is updated.

          To switch to an existing limit group, the switch should be

          The following limits exist and are imposed: limit limits,
          which represent the amount of maximum amount of limits which
          can be and process limits, which represent the maximum num-
          ber of processes which can exist in the group. The kernel
          already imposes limits on the number of files which can be
          opened, so implementing that should be redundant.

          To create a new limit group and restrict the amount of sub-
          limits and processes:

               % <>[10] /mnt/limit/clone
               % echo label mygroup >/mnt/limit/ctl
               % echo mlim 1 >/mnt/limit/ctl
               % echo mproc 20 >/mnt/limit/ctl

          Snippet to attach to an existing limit group, looking for a
          specific label:



               bind '#Λ' /mnt/limit

               for (lgrpstat in `{walk -f /mnt/limit/groups | grep 'status$'}) {
                    lgrpdir=`{basename -d $lgrpstat}
                    lgrplabel=`{cat $lgrpstat | sed 1q}
                    if(~ $lgrplabel $slabel) {
                         <>[10] $lgrpdir/switch
                         exec $prog

               echo lgrp $slabel not found
               exit nolgrp


          Not all processes use pexit , probably the ones which are
          created during boot. This has to be checked.

          Spawning a lot of processes inside a limit group which is
          not the root group can cause a kernel panic related to run-
          lock. Needs to be investigated.