cvs commit: ports/sysutils/cdrdao Makefile distinfo ports/sysutils/cdrdao/files patch-Makefile.in patch-configure patch-dao::ScsiIf-lib.cc patch-dao::cdrdao.drivers patch-dao::dao.cc patch-paranoia::isort.c patch-trackdb::Track.cc patch-trackdb::lec.cc ...

Brian Feldman green at freebsd.org
Sun Jun 13 20:59:42 PDT 2004


On Mon, Jun 14, 2004 at 05:28:35AM +0200, Marius Strobl wrote:
> On Sun, Jun 13, 2004 at 10:14:42PM -0400, Brian Feldman wrote:
> > On Sun, Jun 13, 2004 at 03:01:28PM +0000, Alexander Leidinger wrote:
> > >   - Disable the use of mlockall(2) on FreeBSD 5, even after the last round
> > >     of fixes there are still issues.
> > 
> > What are you referring to?  The issues that are still there should not
> > affect simple mlockall(2) usage.
> > 
> 
> - On i386, depending on the program, mlockall() always returns EAGAIN.
>   E.g. ntpd of the net/ntp port exhibits this problem. This isn't an
>   issue with cdrdao.
> - On sparc64, every call of mlockall(MCL_CURRENT) returns EAGAIN, even
>   in a program just doing that.

Yes, there is a problem with mlockall(2), especially with NTPD: if the
VM space has areas that have no read protection, i.e. PROT_NONElike NTPD
is mapping for some reason, it will fail in this manner.  There are
several possible ways to fix this (one of which I've implemented);
Alan Cox's suggestion to pretend PROT_NONE is PROT_READ when wiring is
much simpler to implement.

Could you cat a /proc/curproc/map from the current running process
on sparc64 after mlockall(2) fails?

> Don't know about the other architectures. So there is no technical
> reason to not to use mlockall() as it no longer seems to have side
> effects (at least not on i386 and sparc64) like random processes
> crashing when another one uses it or causing panics like it did in
> the beginning. But I don't want to frighten the users of a port
> with the warnings that the failing mlockall() causes, especially
> if it is a verbose one like that of cdrecord.

I think it's best to enable mlockall(2) like the software creators
intended and let their documentation handle any confusion by the user.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\


More information about the cvs-all mailing list