Zlatko Calusic wrote:
>
> Rik van Riel <riel@conectiva.com.br> writes:
>
> > On Mon, 25 Dec 2000, Dan Aloni wrote:
> > > On 25 Dec 2000, Zlatko Calusic wrote:
> > >
> > > > Speaking of page_launder() I just stumbled upon two oopsen today on
> > > > the UP build. Maybe it could give a hint to someone, I'm not that good
> > > > at Oops decoding.
> > >
> > > I've decoded the Oops I got, and found that the problem is in
> > > vmscan.c:line-605, where page->mapping is NULL and a_ops gets
> > > resolved and dereferenced at 0x0000000c.
> >
> > The code assumes that every page which has the PG_dirty
> > bit set also has page->mapping set to a valid value.
> >
> > The BUG() people are getting confirms that this assumption
> > is not necessarily true and the VM work that's going on will
> > most likely make it not be true either in some cases.
> >
> > The (trivial) patch below should fix this problem...
> >
> Looking at the patch, I'm practically sure it will cure the symptoms.
> But I'm still slightly worried about those pages we skip in
> there. Maybe we should at least try to discover what are those pages,
> and then maybe it will become obvious what we need (or not) to do with
> them.
>
> Some strategic printk()s could probably give us some clue.
Between line 573 and 594 the page can have 1 user and be unlocked, so it
can be removed by invalidate_inode_pages, and the mapping will be
cleared here:
http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:11 EST