cvs commit: src/sys/kern kern_lockf.c

[Matthew Dillon]

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

    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
    in /etc/ttys.

    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.

						-Matt