cvs commit: src/sys/kern kern_lockf.c
atrens at nortelnetworks.com
Tue May 11 10:28:38 PDT 2004
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.
> 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 :( ...
More information about the Commits