Re: malloc fallout and linprocfs

Kris Kennaway <kris_at_obsecurity.org> writes:
> On Tue, Jan 17, 2006 at 12:50:06PM -0800, Jason Evans wrote:
> > On Jan 17, 2006, at 12:41 PM, Steve Kargl wrote:
> > > KDB: stack backtrace:
> > > witness_warn() at witness_warn+0x262
> > > uma_zalloc_arg() at uma_zalloc_arg+0x217
> > > malloc() at malloc+0xa3
> > > vn_fullpath() at vn_fullpath+0x56
> > > linprocfs_doprocmaps() at linprocfs_doprocmaps+0x31e
> > > pfs_read() at pfs_read+0x260
> > > VOP_READ_APV() at VOP_READ_APV+0x74
> > > vn_read() at vn_read+0x14f
> > > dofileread() at dofileread+0x94
> > > kern_readv() at kern_readv+0x60
> > > read() at read+0x4a
> > > ia32_syscall() at ia32_syscall+0x178
> > > Xint0x80_syscall() at Xint0x80_syscall+0x5d
> > > malloc(M_WAITOK) of "1024", forcing M_NOWAIT with the following non-sleepable locks held:
> > > exclusive sleep mutex vm object (standard object) r = 0 (0xffffff02b7846640) locked _at_ /usr/src/sys/compat/linprocfs/linprocfs.c:874
> > I don't think that libc's malloc is a factor here; the stacktrace
> > above is all in the kernel, isn't it?
> Yeah, must be some other bug.

linprocfs_doprocmaps() calls vn_fullpath() while holding a mutex, but
vn_fullpath() calls malloc(M_WAITOK); bad idea.  Luckily for Steve,
WITNESS spotted it and turned it into a less severe error (not
checking the return value of malloc(M_NOWAIT)).  Without WITNESS, the
following is a good panic(9) implementation:

$ cat /compat/linux/proc/self/maps

I'm not entirely sure how to fix it, though.  It might be OK to just
remove the VM_OBJECT_LOCK() / VM_OBJECT_UNLOCK() calls.

DES
-- 
Dag-Erling Smørgrav - des_at_des.no