lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 May 2007 12:11:14 +1000 From: David Chinner <dgc@....com> To: Michal Piotrowski <michal.k.k.piotrowski@...il.com> Cc: Christoph Hellwig <hch@....de>, xfs-masters@....sgi.com, Andrew Morton <akpm@...ux-foundation.org>, David Chinner <dgc@....com>, linux-kernel@...r.kernel.org Subject: Re: [xfs-masters] Re: 2.6.22-rc1-mm1 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists