bin/115430: [rpc.statd] rpc.statd core dumps if unable to mmap() /var/db/statd.status file

Don Lewis truckman at FreeBSD.org
Sun Aug 12 16:40:07 PDT 2007


The following reply was made to PR bin/115430; it has been noted by GNATS.

From: Don Lewis <truckman at FreeBSD.org>
To: timur at FreeBSD.org
Cc: bug-followup at FreeBSD.org, maxim at macomnet.ru
Subject: Re: bin/115430: [rpc.statd] rpc.statd core dumps if unable to
 mmap() /var/db/statd.status file
Date: Sun, 12 Aug 2007 16:38:35 -0700 (PDT)

 On 13 Aug, Timur I. Bakeyev wrote:
 > On Sun, Aug 12, 2007 at 09:52:04PM +0000, truckman at FreeBSD.org wrote:
 >> Synopsis: [rpc.statd] rpc.statd core dumps if unable to mmap() /var/db/statd.status file
 >> 
 >> State-Changed-Why: 
 >> The mmap() failure is fixed in:
 >>   usr.sbin/rpc.statd/statd.c 1.15 (Sun Aug 5 16:33:06 2007 UTC) -      HEAD
 >>   usr.sbin/rpc.statd/statd.c 1.12.8.2 (Sun Aug 12 01:46:19 2007 UTC) - RELENG_6
 > 
 > No, I don't think the bug is fixed. Your fix addressed the reason why
 > mmap() fails to me, thanks. But the errorneous execution flow in a
 > file.c still in place - should, by any other reason, mmap() fails for
 > rpc.statd again - we'll get another perfect coredump to fix.
 > 
 > Patching code around the faulty condition to prevent it to be trigged is
 > never safe - it'll always be another reason for it to fail. If you so
 > confident that your fix makes it impossible for mmap() to fail in the
 > init_file() - replace:
 > 
 > warn("unable to mmap() status file");
 > 
 > with err(). Still I prefer cleaner solution, which just doesn't try to
 > dereference bogus pointer.
 
 I've already made a request to re@ to replace warn() with err(). There's
 no reason for execution to continue if mmap() were to somehow fail, and
 failure of mmap() is not a good reason to drop a core file.
 
 That said, I just looked through all the possible error returns on the
 mmap(2) man page, and none of the other failures look possible with the
 rpc.statd code.  I suppose mmap() could still fail if the sysadmin set 
 vm.max_proc_mmap to a small value, but that would likely break all sorts
 of other things.
 


More information about the freebsd-bugs mailing list