tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RLIMIT_FSIZE and SIGXFSZ



In article <201311160540.AAA23094%Chip.Rodents-Montreal.ORG@localhost>,
Mouse  <mouse%Rodents-Montreal.ORG@localhost> wrote:
>The documentation I have (which is consistent across 1.4T, 4.0.1, and
>5.2) says that "[a] file I/O operation that would create a file larger
>that the process' soft limit will cause the write to fail and a signal
>SIGXFSZ to be generated".  I looked at the code (for 4.0.1, that being
>what's on the machine I care about at the moment) and this appears to
>be accurate.
>
>It seems to me it would be more useful to do something like what
>RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
>them only when the size exceeds the hard limit.  As it stands, the hard
>limit is useful only as a value the soft limit can't be raised above.
>("More useful" to me, at any rate.)
>
>It looks fairly simple to do.  UFS, for example, says
>(ufs/ufs/ufs_readwrite.c)
>
>       l = curlwp;
>       if (vp->v_type == VREG && l &&
>           uio->uio_offset + uio->uio_resid >
>           l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_cur) {
>               psignal(l->l_proc, SIGXFSZ);
>               return (EFBIG);
>       }
>
>and I can't see any reason it wouldn't work to
>
>       l = curlwp;
>       if (vp->v_type == VREG && l &&
>           uio->uio_offset + uio->uio_resid >
>           l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_cur) {
>               psignal(l->l_proc, SIGXFSZ);
>-              return (EFBIG);
>+              if (uio->uio_offset + uio->uio_resid >
>+                  l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_max)
>+                      return (EFBIG);
>       }
>
>with a corresponding change to getrlimit(2) to describe the new
>behaviour (and, of course, similar changes in the other places SIGXFSZ
>is generated).
>
>Comments or other thoughts?

I don't think it is used too much so the behavior change should not be
a problem. The more consistently the limits work, the better off we are
in the long run.

christos



Home | Main Index | Thread Index | Old Index