In article <[email protected]>, Mouse <[email protected]> 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
