kern/39206: ffs um_lock handling isn't great

[Simon Burge <simonb%NetBSD.org@localhost>]

>Number:         39206
>Category:       kern
>Synopsis:       ffs um_lock handling isn't great
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 25 14:15:00 +0000 2008
>Originator:     Simon Burge
>Release:        NetBSD -current, mid 2008
>Organization:
>Environment:
        Architecture: any
        Machine: any
>Description:
        (struct ufs_mount *)->um_lock handling is a bit suspect,
        and seems to be released/gained fairly freely leaving the
        possibility of race conditions.

        One example pointed out by pooka@ is at the top of
        ffs_alloccg().  It appears that once the free block check at
        the top of this function succeeds, this function isn't allowed
        to fail.  This is noted in the "XXX fvdl mapsearch ..." comment
        further down.  This function is entered with um_lock held, and
        once the free block check has passed um_lock is dropped.  This
        then allows another thread to reach the same point, and could
        lead to problems if there was only one block free in the CG
        before the first thread get there.

        This PR is entered as priority "medium" and not "high" since no
        actual problems have been observed in practice yet.

>How-To-Repeat:
        Code inspection.  Pooka suggested introducing a sleep after
        um_lock is dropped at the top of ffs_alloccg() and have more
        than one thread trying to allocate blocks in the filesystem.

>Fix:
        None given.