Re: [xfs-masters] Re: 2.6.22-rc1-mm1

[Michal Piotrowski]

Hi David,

On 21/05/07, David Chinner <dgc@xxxxxxx> wrote:
> On Fri, May 18, 2007 at 12:11:14PM +1000, David Chinner wrote:
> > On Thu, May 17, 2007 at 10:05:11PM +0200, Michal Piotrowski wrote:
> > > I applied your patch and I get another oops
> > >
> > > [  261.491499] XFS mounting filesystem loop0
> > > [  261.501641] Ending clean XFS mount for filesystem: loop0
> > > [  261.507698] SELinux: initialized (dev loop0, type xfs), uses xattr
> > > [  261.567441] XFS mounting filesystem loop0
> > > [  261.573931] allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
> > > [  261.582935] xfs_buf_get_noaddr: failed to map pages
> > > [  261.592478] Ending clean XFS mount for filesystem: loop0
> > > [  261.618543] SELinux: initialized (dev loop0, type xfs), uses xattr
> > > [  261.691563] XFS mounting filesystem loop0
> > > [  261.698927] allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
> > >                                   ^^^^^^^^^^^^^^^^^^^^
> > >                                   interesting
> >
> > Yeah, looks like a vmalloc leak is occurring. I haven't noticed
> > it before because:
> >
> > VmallocTotal: 137427898368 kB
> > VmallocUsed:   3128272 kB
> > VmallocChunk: 137424770048 kB
> >
> > It takes a long time to leak enough vmapped space to run out on ia64...
> >
> > That tends to imply we have a mapped buffer being leaked somewhere.
> > Interestingly, I don't see a memory leak so we must be freeing the
> > memory associated with the buffer, just not unmapping it first. Not
> > sure how that can happen yet.....
> .....
> >
> > Looks like we're leaking 272kB of vmalloc space on each mount/unmount
> > cycle. I'm trying to track this down now....
>
> I've found what is going on here - kmem_alloc() is decidedly more
> forgiving than manually built page arrays and vmap/vunmap. Prior
> to this change we wouldn't have even leaked memory....
>
> Christoph - this is an interaction with xfs_buf_associate_memory();
> I'm not sure what it is doing is at all safe now that it never gets
> passed kmem_alloc()d memory - it works for the log recovery case
> because we use it in pairs - once to shorten the buffer and then once
> to put it back the way it was.
>
> But that doesn't work for the log buffers (we never return them to their
> original state) and the log wrap case looks to work mostly by accident
> now (and could posibly lead to double freeing pages)....
>
> It seems that what we really need with the new code is a xfs_buf_clone()
> operation followed by trimming the range to what the secondary I/O needs
> to span. This would work for the log buffer case as well. Your thoughts?
>
> In the meantime, the following patch appears to fix the leak.

After a few minutes of mount/umount cycle everything seems to be ok,
problem fixed.

Thanks!

> Cheers,
>
> Dave.

Regards,
Michal

--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/