cvs commit: src/sys/kern kern_lockf.c

[Andrew Atrens]

Matthew Dillon wrote:

> 
> :>     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
> 
>     Not a whole lot.  I have run test after test on my boxes but none of
>     them mess around with posix locks, and I haven't had any failures
>     for days.
> 
>     My personal workstation is using 2.  Using gdb I determined that
>     'xdm' (XFree86) is using a POSIX lock, and something else must be
>     using an flock.
> 
>     Samba uses a lot of POSIX locks.  The panic bugs seem to be corrected,
>     I was able to install samba on my test box and access it from my one
>     windowz box.
> 
>     Bug reports so far:
> 
>     Andrew Atrens: (w/ kern.mmxopt=0) - general VM corruption, panics
>     in vm_page_alloc().  UFS corruption.  binaries mounted via NFS
>     containing corruption which goes away after a reboot.

In one instance (happened last week) mplayer wouldn't start because the
first 4096 bytes of libggi.so.2 had been zeroed. I know this because while
the system was in the bad state I made a copy of libggi.so.2 with cp, then
rebooted and compared it to the original. The files had identical size, the
only difference was the first 4096 bytes. I should have done the same test
with the bad compiler binary yesterday :( ...

Andrew