Re: cvs commit: src/sys/kern kern_lockf.c

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

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.
> :
> :Joerg
> 
>     Noooooo.  Damn.  I thought I had it, but you are right.  That can't be
>     it.

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
do that.

> 
>     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.

Joerg

> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>