cvs commit: src/sys/kern kern_lockf.c
joerg at britannica.bec.de
Tue May 11 08:22:53 PDT 2004
On Tue, May 11, 2004 at 07:59:29AM -0700, Matthew Dillon wrote:
> :Matt, lf_destroy_range called with accounting == 0 doesn't follow any
> :pointer in the range, it just uses the values directly. This is not the
> :bug which corrupts the memory.
> Noooooo. Damn. I thought I had it, but you are right. That can't be
In fact, I thought about using M_ZERO first, but since the range is
always explicitly initialized before being put into the lists, I didn't
> I still believe that the issue is related to the lockf code, somewhere.
> It's the only thing that fits the reports.
You could try stress testing the lockf code with the test case I commited,
but after reading through the whole code, I'm at least sure it doesn't
follow any pointer it should not. I'm going through the other changes later,
there is a lot which has changed. Anyway, I fully agree on the kernel update,
since the other problems e.g. at are fixed.
> Maybe the problem is more indirect... the earlier bug I had fixed was
> the error return code from lf_setlock().... it was returning success
> even if it failed. But the only way that could cause system corruption
> would be if it had an adverse effect on something like X, and I don't
> see how.
It could lead to corruption e.g. of a database, but not of a filesystem.
There aren't that many users of POSIX locks in the base system.
> Matthew Dillon
> <dillon at xxxxxxxxxxxxx>
More information about the Commits