Date: Sun, 12 Aug 2007 23:40:07 GMT From: Don Lewis <truckman@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/115430: [rpc.statd] rpc.statd core dumps if unable to mmap() /var/db/statd.status file Message-ID: <200708122340.l7CNe7SF003553@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/115430; it has been noted by GNATS.
From: Don Lewis <truckman@FreeBSD.org>
To: timur@FreeBSD.org
Cc: bug-followup@FreeBSD.org, maxim@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708122340.l7CNe7SF003553>