[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/39206: ffs um_lock handling isn't great
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).
Main Index |
Thread Index |