[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/39206: ffs um_lock handling isn't great
>Synopsis: ffs um_lock handling isn't great
>Arrival-Date: Fri Jul 25 14:15:00 +0000 2008
>Originator: Simon Burge
>Release: NetBSD -current, mid 2008
(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.
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.
Main Index |
Thread Index |