cvs commit: src/sys/kern kern_lockf.c
dillon at apollo.backplane.com
Tue May 11 09:46:20 PDT 2004
:> 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
My personal workstation is using 2. Using gdb I determined that
'xdm' (XFree86) is using a POSIX lock, and something else must be using
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
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.
David Rhodus: Similar VM crash: panic: zone: entry not free
David Rhodus: One of my users was trying to play with mgetty+sendfax
and somehow parts of /etc/passwd and also NUL'd out sections wound up
Me: related VM crash a week ago (unable to repeat).
The M.O. is the same for all of them... general VM page cache corruption.
It's like a page is being freed and reused improperly. It does sound
like it might not be lockf related.
In fact, now that I think about it, both my workstation and test box
are not using the PIPE code in standard SFBUF mode, and they are not
having any problems.
I will check the PIPE/SFBUF code. Maybe it's related to SFBUFs.
More information about the Commits