Date: Wed, 5 Aug 2009 22:38:25 +0400 From: pluknet <pluknet@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: softdep_setup_freeblocks: kmem_malloc(4096): kmem_map too small Message-ID: <a31046fc0908051138g8a0c188rbf6e4c08f9036c7b@mail.gmail.com> In-Reply-To: <a31046fc0908050932lc3191fbl88459c39e29c08ec@mail.gmail.com> References: <a31046fc0908042238u2a920cecmbed34f5e0c73c1cb@mail.gmail.com> <20090805155539.GN1884@deviant.kiev.zoral.com.ua> <a31046fc0908050932lc3191fbl88459c39e29c08ec@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/8/5 pluknet <pluknet@gmail.com>: > 2009/8/5 Kostik Belousov <kostikbel@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): >>> =A0 =A0 Filesystem =A0 usage =A0 quota =A0 limit =A0 grace =A0 files = =A0 quota =A0 limit =A0 grace >>> =A0 =A0 =A0 =A0 =A0/home 6172656 6172672 6172672 =A0 =A0 =A0 =A0 =A0 14= 723 =A0 =A0 =A0 0 =A0 =A0 =A0 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: =A0kmem_malloc(4096): kmem_map too small: 335544320 total alloca= ted >>> >>> 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+0x7= d >>> 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+0= x77 >>> 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 =3D 0x281ae32f, esp =3D 0xbf= bfbbdc, ebp =3D >>> =A00xbfbfbbf8 --- >> >> 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. --=20 wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0908051138g8a0c188rbf6e4c08f9036c7b>