softdep_setup_freeblocks: kmem_malloc(4096): kmem_map too small

[pluknet]

2009/8/5 pluknet <pluknet at gmail.com>:
> 2009/8/5 Kostik Belousov <kostikbel at gmail.com>:
>> On Wed, Aug 05, 2009 at 09:38:13AM +0400, pluknet wrote:
>>> Hi.
>>>
>>> We have a problem with user running with exceed quota:
>>>
>>> Disk quotas for user eviluser (uid 9181):
>>>     Filesystem   usage   quota   limit   grace   files   quota   limit   grace
>>>          /home 6172656 6172672 6172672           14723       0       0
>>>
>>> Some types of ufs operations running under him lead to kernel
>>> panic due to out of kernel memory (tested on 6.2-R, and 6.4-R):
>>>
>>> db> x/s *panicstr
>>> buf.1:  kmem_malloc(4096): kmem_map too small: 335544320 total allocated
>>>
>>> Upping the higher level of vm.kmem_size_max doesn't help much,
>>> postponing that panic little farther.
>>>
>>> db> bt
>>> Tracing pid 7242 tid 100772 td 0xca7a57d0
>>> kdb_enter(c0924e28) at kdb_enter+0x2b
>>> panic(c093a575,1000,14000000,c17f7818,0,...) at panic+0x127
>>> kmem_malloc(c10680c0,1000,402,ef34e7bc,c07fb86d,...) at kmem_malloc+0x7d
>>> page_alloc(c10613c0,1000,ef34e7af,402,0,...) at page_alloc+0x1a
>>> slab_zalloc(c10613c0,402,c1061480,c10613c0,da68220c,...) at slab_zalloc+0xdd
>>> uma_zone_slab(c10613c0,502) at uma_zone_slab+0xe8
>>> uma_zalloc_bucket(c10613c0,502) at uma_zalloc_bucket+0x15c
>>> uma_zalloc_arg(c10613c0,0,502) at uma_zalloc_arg+0x292
>>> malloc(b8,c09d4ba0,502,0,0,...) at malloc+0x46
>>> softdep_setup_freeblocks(cc8fb18c,0,0,800,cc8fb18c,ffffffe0,ffffffff,0,0) at sof
>>> tdep_setup_freeblocks+0x48
>>> ffs_truncate(c89e3990,0,0,800,c94f4300,...) at ffs_truncate+0x5cb
>>> ffs_write(ef34ebec) at ffs_write+0x603
>>> VOP_WRITE_APV(c09d5960,ef34ebec) at VOP_WRITE_APV+0xce
>>> vn_write(caba7000,ef34ecbc,c94f4300,0,ca7a57d0) at vn_write+0x1ee
>>> dofilewrite(ca7a57d0,7,caba7000,ef34ecbc,ffffffff,...) at dofilewrite+0x77
>>> kern_writev(ca7a57d0,7,ef34ecbc,7e99c3c,42f6e8,...) at kern_writev+0x3b
>>> write(ca7a57d0,ef34ed04) at write+0x45
>>> syscall(3b,82b003b,bfbf003b,8851,82bb000,...) at syscall+0x2bf
>>> Xint0x80_syscall() at Xint0x80_syscall+0x1f
>>> --- syscall (4, FreeBSD ELF32, write), eip = 0x281ae32f, esp = 0xbfbfbbdc, ebp =
>>>  0xbfbfbbf8 ---
>>
>> I have a high confidence that this issue should be fixed by r170991 and
>> by minor followup in r183067.
>>
>>
>
> r170991 was MFC'ed before 6.4, and r183067 wasn't MFC'ed to RELENG_6..
> I'll try and report later. Thanks.
>

It seems to not work.
It just panicked again with applied r183067, same backtrace output.

-- 
wbr,
pluknet