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.....
mount xfsVmallocUsed: 177808 kB
unmount xfs
mount xfsVmallocUsed: 178080 kB
unmount xfs
mount xfsVmallocUsed: 178352 kB
unmount xfs
mount xfsVmallocUsed: 178624 kB
unmount xfs
mount xfsVmallocUsed: 178896 kB
unmount xfs
mount xfsVmallocUsed: 179168 kB
unmount xfs
mount xfsVmallocUsed: 179440 kB
unmount xfs
mount xfsVmallocUsed: 179712 kB
unmount xfs
mount xfsVmallocUsed: 179984 kB
Looks like we're leaking 272kB of vmalloc space on each mount/unmount
cycle. I'm trying to track this down now....
> [ 265.856480] Ending clean XFS mount for filesystem: loop0
> [ 265.862260] SELinux: initialized (dev loop0, type xfs), uses xattr
> [ 265.921288] XFS mounting filesystem loop0
> [ 265.927123] xfs_buf_get_noaddr: failed to map pages
> [ 265.932575] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
....
> [ 266.077866] Call Trace:
> [ 266.080611] [<fdc75a12>] xlog_alloc_log+0x1b9/0x2cd [xfs]
> [ 266.086286] [<fdc75cd1>] xfs_log_mount+0x6b/0xf1 [xfs]
> [ 266.091688] [<fdc7ec47>] xfs_mountfs+0x959/0xc4a [xfs]
Groan - ASSERT(0) is the error handling there for debug kernels. If we fail
to allocate an iclogbuf on a non-debug kernel, it will panic like this.
I'll deal with that later....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]