On 2008.03.28 13:21:38 -0700, Linus Torvalds wrote:
quoted text
> On Fri, 28 Mar 2008, Arjan van de Ven wrote:
> > 
> > Rank 1: input_release_device
> > 	This appears to be a regression in 2.6.25; the first reports show up
> > in 2.6.25-rc2		Often a warning at kernel/mutex.c:134
> > (mutex_lock_nested), but some oopses too
> 
> The oopses (at least some of them) seem to be a use-after-free where we 
> seem to do a list_add() on an already-released list head (or we didn't 
> remove the previous/next entry from a list before we free'd it, and then 
> the next list_add() will follow a bogus pointer).
> 
> > http://www.kerneloops.org/searchweek.php?search=input_release_device
> 
> The problem with kerneloops is that it seems to be really hard to figure 
> out the *source* of the oops. I can find the oopses (and it's really good 
> with the whole search-and-clump-together-by-version thing), but then when 
> some oops like this is found, it's hard to see where your kerneloops 
> scripts found the oops from, so the context of the oops is all gone.
> 
> Is there something obvious that I'm missing? I'd really like to see the 
> whole posting that the oops came from. Do you save the originals or even 
> just message ID's from the ones you pick from emails?

The oops for that one seem to be all coming from fc9 systems, which
(IIRC) include the automatic kerneloops reporting tool, so there
probably is no mail for them. Those that come from a mailing list
usually have a link at the top, for example this one:
http://www.kerneloops.org/raw.php?rawid=5735&msgid=http://mid.gmane.org/20080327230430...

Björn
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/