Re: kern/39206: ffs um_lock handling isn't great

[Antti Kantee <pooka%cs.hut.fi@localhost>]

The following reply was made to PR kern/39206; it has been noted by GNATS.

From: Antti Kantee <pooka%cs.hut.fi@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: Simon Burge <simonb%NetBSD.org@localhost>, gnats-bugs%netbsd.org@localhost,
        kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/39206: ffs um_lock handling isn't great
Date: Fri, 25 Jul 2008 19:44:18 +0300

 On Fri Jul 25 2008 at 15:24:44 +0000, David Holland wrote:
 > On Fri, Jul 25, 2008 at 02:15:00PM +0000, Simon Burge wrote:
 >  >         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.
 > 
 > Unless this is the source of those occasional "ffs_alloccg: map
 > corrupted" panics...
 
 If we are talking about pre-vmlocking corruption, I doubt it.  Unless,
 of course, this code is entered from interrupt context with the help of
 softdep (which I am not sure of and won't bother to read the code now).