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